2016-01-21 03:51:34 +01:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
2019-08-13 06:53:41 +02:00
|
|
|
* standbydefs.h
|
2016-01-21 03:51:34 +01:00
|
|
|
* Frontend exposed definitions for hot standby mode.
|
|
|
|
*
|
|
|
|
*
|
2023-01-02 21:00:37 +01:00
|
|
|
* Portions Copyright (c) 1996-2023, PostgreSQL Global Development Group
|
2016-01-21 03:51:34 +01:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
|
|
|
*
|
|
|
|
* src/include/storage/standbydefs.h
|
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
#ifndef STANDBYDEFS_H
|
|
|
|
#define STANDBYDEFS_H
|
|
|
|
|
|
|
|
#include "access/xlogreader.h"
|
|
|
|
#include "lib/stringinfo.h"
|
|
|
|
#include "storage/lockdefs.h"
|
Emit invalidations to standby for transactions without xid.
So far, when a transaction with pending invalidations, but without an
assigned xid, committed, we simply ignored those invalidation
messages. That's problematic, because those are actually sent for a
reason.
Known symptoms of this include that existing sessions on a hot-standby
replica sometimes fail to notice new concurrently built indexes and
visibility map updates.
The solution is to WAL log such invalidations in transactions without an
xid. We considered to alternatively force-assign an xid, but that'd be
problematic for vacuum, which might be run in systems with few xids.
Important: This adds a new WAL record, but as the patch has to be
back-patched, we can't bump the WAL page magic. This means that standbys
have to be updated before primaries; otherwise
"PANIC: standby_redo: unknown op code 32" errors can be encountered.
XXX:
Reported-By: Васильев Дмитрий, Masahiko Sawada
Discussion:
CAB-SwXY6oH=9twBkXJtgR4UC1NqT-vpYAtxCseME62ADwyK5OA@mail.gmail.com
CAD21AoDpZ6Xjg=gFrGPnSn4oTRRcwK1EBrWCq9OqOHuAcMMC=w@mail.gmail.com
2016-04-24 04:18:00 +02:00
|
|
|
#include "storage/sinval.h"
|
2016-01-21 03:51:34 +01:00
|
|
|
|
|
|
|
/* Recovery handlers for the Standby Rmgr (RM_STANDBY_ID) */
|
|
|
|
extern void standby_redo(XLogReaderState *record);
|
|
|
|
extern void standby_desc(StringInfo buf, XLogReaderState *record);
|
|
|
|
extern const char *standby_identify(uint8 info);
|
Emit invalidations to standby for transactions without xid.
So far, when a transaction with pending invalidations, but without an
assigned xid, committed, we simply ignored those invalidation
messages. That's problematic, because those are actually sent for a
reason.
Known symptoms of this include that existing sessions on a hot-standby
replica sometimes fail to notice new concurrently built indexes and
visibility map updates.
The solution is to WAL log such invalidations in transactions without an
xid. We considered to alternatively force-assign an xid, but that'd be
problematic for vacuum, which might be run in systems with few xids.
Important: This adds a new WAL record, but as the patch has to be
back-patched, we can't bump the WAL page magic. This means that standbys
have to be updated before primaries; otherwise
"PANIC: standby_redo: unknown op code 32" errors can be encountered.
XXX:
Reported-By: Васильев Дмитрий, Masahiko Sawada
Discussion:
CAB-SwXY6oH=9twBkXJtgR4UC1NqT-vpYAtxCseME62ADwyK5OA@mail.gmail.com
CAD21AoDpZ6Xjg=gFrGPnSn4oTRRcwK1EBrWCq9OqOHuAcMMC=w@mail.gmail.com
2016-04-24 04:18:00 +02:00
|
|
|
extern void standby_desc_invalidations(StringInfo buf,
|
|
|
|
int nmsgs, SharedInvalidationMessage *msgs,
|
|
|
|
Oid dbId, Oid tsId,
|
|
|
|
bool relcacheInitFileInval);
|
2016-01-21 03:51:34 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* XLOG message types
|
|
|
|
*/
|
|
|
|
#define XLOG_STANDBY_LOCK 0x00
|
|
|
|
#define XLOG_RUNNING_XACTS 0x10
|
Emit invalidations to standby for transactions without xid.
So far, when a transaction with pending invalidations, but without an
assigned xid, committed, we simply ignored those invalidation
messages. That's problematic, because those are actually sent for a
reason.
Known symptoms of this include that existing sessions on a hot-standby
replica sometimes fail to notice new concurrently built indexes and
visibility map updates.
The solution is to WAL log such invalidations in transactions without an
xid. We considered to alternatively force-assign an xid, but that'd be
problematic for vacuum, which might be run in systems with few xids.
Important: This adds a new WAL record, but as the patch has to be
back-patched, we can't bump the WAL page magic. This means that standbys
have to be updated before primaries; otherwise
"PANIC: standby_redo: unknown op code 32" errors can be encountered.
XXX:
Reported-By: Васильев Дмитрий, Masahiko Sawada
Discussion:
CAB-SwXY6oH=9twBkXJtgR4UC1NqT-vpYAtxCseME62ADwyK5OA@mail.gmail.com
CAD21AoDpZ6Xjg=gFrGPnSn4oTRRcwK1EBrWCq9OqOHuAcMMC=w@mail.gmail.com
2016-04-24 04:18:00 +02:00
|
|
|
#define XLOG_INVALIDATIONS 0x20
|
2016-01-21 03:51:34 +01:00
|
|
|
|
|
|
|
typedef struct xl_standby_locks
|
|
|
|
{
|
|
|
|
int nlocks; /* number of entries in locks array */
|
|
|
|
xl_standby_lock locks[FLEXIBLE_ARRAY_MEMBER];
|
|
|
|
} xl_standby_locks;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* When we write running xact data to WAL, we use this structure.
|
|
|
|
*/
|
|
|
|
typedef struct xl_running_xacts
|
|
|
|
{
|
|
|
|
int xcnt; /* # of xact ids in xids[] */
|
|
|
|
int subxcnt; /* # of subxact ids in xids[] */
|
|
|
|
bool subxid_overflow; /* snapshot overflowed, subxids missing */
|
2020-08-11 20:25:23 +02:00
|
|
|
TransactionId nextXid; /* xid from ShmemVariableCache->nextXid */
|
2016-01-21 03:51:34 +01:00
|
|
|
TransactionId oldestRunningXid; /* *not* oldestXmin */
|
|
|
|
TransactionId latestCompletedXid; /* so we can set xmax */
|
|
|
|
|
|
|
|
TransactionId xids[FLEXIBLE_ARRAY_MEMBER];
|
|
|
|
} xl_running_xacts;
|
|
|
|
|
Emit invalidations to standby for transactions without xid.
So far, when a transaction with pending invalidations, but without an
assigned xid, committed, we simply ignored those invalidation
messages. That's problematic, because those are actually sent for a
reason.
Known symptoms of this include that existing sessions on a hot-standby
replica sometimes fail to notice new concurrently built indexes and
visibility map updates.
The solution is to WAL log such invalidations in transactions without an
xid. We considered to alternatively force-assign an xid, but that'd be
problematic for vacuum, which might be run in systems with few xids.
Important: This adds a new WAL record, but as the patch has to be
back-patched, we can't bump the WAL page magic. This means that standbys
have to be updated before primaries; otherwise
"PANIC: standby_redo: unknown op code 32" errors can be encountered.
XXX:
Reported-By: Васильев Дмитрий, Masahiko Sawada
Discussion:
CAB-SwXY6oH=9twBkXJtgR4UC1NqT-vpYAtxCseME62ADwyK5OA@mail.gmail.com
CAD21AoDpZ6Xjg=gFrGPnSn4oTRRcwK1EBrWCq9OqOHuAcMMC=w@mail.gmail.com
2016-04-24 04:18:00 +02:00
|
|
|
/*
|
|
|
|
* Invalidations for standby, currently only when transactions without an
|
|
|
|
* assigned xid commit.
|
|
|
|
*/
|
|
|
|
typedef struct xl_invalidations
|
|
|
|
{
|
|
|
|
Oid dbId; /* MyDatabaseId */
|
|
|
|
Oid tsId; /* MyDatabaseTableSpace */
|
Fix bugs in vacuum of shared rels, by keeping their relcache entries current.
When vacuum processes a relation it uses the corresponding relcache
entry's relfrozenxid / relminmxid as a cutoff for when to remove
tuples etc. Unfortunately for nailed relations (i.e. critical system
catalogs) bugs could frequently lead to the corresponding relcache
entry being stale.
This set of bugs could cause actual data corruption as vacuum would
potentially not remove the correct row versions, potentially reviving
them at a later point. After 699bf7d05c some corruptions in this vein
were prevented, but the additional error checks could also trigger
spuriously. Examples of such errors are:
ERROR: found xmin ... from before relfrozenxid ...
and
ERROR: found multixact ... from before relminmxid ...
To be caused by this bug the errors have to occur on system catalog
tables.
The two bugs are:
1) Invalidations for nailed relations were ignored, based on the
theory that the relcache entry for such tables doesn't
change. Which is largely true, except for fields like relfrozenxid
etc. This means that changes to relations vacuumed in other
sessions weren't picked up by already existing sessions. Luckily
autovacuum doesn't have particularly longrunning sessions.
2) For shared *and* nailed relations, the shared relcache init file
was never invalidated while running. That means that for such
tables (e.g. pg_authid, pg_database) it's not just already existing
sessions that are affected, but even new connections are as well.
That explains why the reports usually were about pg_authid et. al.
To fix 1), revalidate the rd_rel portion of a relcache entry when
invalid. This implies a bit of extra complexity to deal with
bootstrapping, but it's not too bad. The fix for 2) is simpler,
simply always remove both the shared and local init files.
Author: Andres Freund
Reviewed-By: Alvaro Herrera
Discussion:
https://postgr.es/m/20180525203736.crkbg36muzxrjj5e@alap3.anarazel.de
https://postgr.es/m/CAMa1XUhKSJd98JW4o9StWPrfS=11bPgG+_GDMxe25TvUY4Sugg@mail.gmail.com
https://postgr.es/m/CAKMFJucqbuoDRfxPDX39WhA3vJyxweRg_zDVXzncr6+5wOguWA@mail.gmail.com
https://postgr.es/m/CAGewt-ujGpMLQ09gXcUFMZaZsGJC98VXHEFbF-tpPB0fB13K+A@mail.gmail.com
Backpatch: 9.3-
2018-06-12 20:13:21 +02:00
|
|
|
bool relcacheInitFileInval; /* invalidate relcache init files */
|
Emit invalidations to standby for transactions without xid.
So far, when a transaction with pending invalidations, but without an
assigned xid, committed, we simply ignored those invalidation
messages. That's problematic, because those are actually sent for a
reason.
Known symptoms of this include that existing sessions on a hot-standby
replica sometimes fail to notice new concurrently built indexes and
visibility map updates.
The solution is to WAL log such invalidations in transactions without an
xid. We considered to alternatively force-assign an xid, but that'd be
problematic for vacuum, which might be run in systems with few xids.
Important: This adds a new WAL record, but as the patch has to be
back-patched, we can't bump the WAL page magic. This means that standbys
have to be updated before primaries; otherwise
"PANIC: standby_redo: unknown op code 32" errors can be encountered.
XXX:
Reported-By: Васильев Дмитрий, Masahiko Sawada
Discussion:
CAB-SwXY6oH=9twBkXJtgR4UC1NqT-vpYAtxCseME62ADwyK5OA@mail.gmail.com
CAD21AoDpZ6Xjg=gFrGPnSn4oTRRcwK1EBrWCq9OqOHuAcMMC=w@mail.gmail.com
2016-04-24 04:18:00 +02:00
|
|
|
int nmsgs; /* number of shared inval msgs */
|
|
|
|
SharedInvalidationMessage msgs[FLEXIBLE_ARRAY_MEMBER];
|
|
|
|
} xl_invalidations;
|
|
|
|
|
|
|
|
#define MinSizeOfInvalidations offsetof(xl_invalidations, msgs)
|
|
|
|
|
2016-01-21 03:51:34 +01:00
|
|
|
#endif /* STANDBYDEFS_H */
|