Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commit135f4f6

Browse files
committed
Don't advance checkPoint.nextXid near the end of a checkpoint sequence.
This reverts commitc111306 in favor ofactually fixing the problem: namely, that we should never have beenmodifying the checkpoint record's nextXid at this point to begin with.The nextXid should match the state as of the checkpoint's logical WALposition (ie the redo point), not the state as of its physical position.It's especially bogus to advance it in some wal_levels and not others.In any case there is no need for the checkpoint record to carry thesame nextXid shown in the XLOG_RUNNING_XACTS record just emitted byLogStandbySnapshot, as any replay operation will already have adoptedthat value as current.This fixes bug #7710 from Tarvi Pillessaar, and probably also explains bug#6291 from Daniel Farina, in that if a checkpoint were in progress at theinstant of XID wraparound, the epoch bump would be lost as reported.(And, of course, these days there's at least a 50-50 chance of a checkpointbeing in progress at any given instant.)Diagnosed by me and independently by Andres Freund. Back-patch to allbranches supporting hot standby.
1 parent069aa39 commit135f4f6

File tree

3 files changed

+3
-14
lines changed

3 files changed

+3
-14
lines changed

‎src/backend/access/transam/xlog.c

Lines changed: 1 addition & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -7422,18 +7422,9 @@ CreateCheckPoint(int flags)
74227422
*
74237423
* If we are shutting down, or Startup process is completing crash
74247424
* recovery we don't need to write running xact data.
7425-
*
7426-
* Update checkPoint.nextXid since we may have a later value. If we
7427-
* do update the value, and we have wrapped, increment epoch also.
74287425
*/
74297426
if (!shutdown&&XLogStandbyInfoActive())
7430-
{
7431-
TransactionIdprevXid=checkPoint.nextXid;
7432-
7433-
LogStandbySnapshot(&checkPoint.nextXid);
7434-
if (checkPoint.nextXid<prevXid)
7435-
checkPoint.nextXidEpoch++;
7436-
}
7427+
LogStandbySnapshot();
74377428

74387429
START_CRIT_SECTION();
74397430

‎src/backend/storage/ipc/standby.c

Lines changed: 1 addition & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -869,7 +869,7 @@ standby_desc(StringInfo buf, uint8 xl_info, char *rec)
869869
* from a time when they were possible.
870870
*/
871871
void
872-
LogStandbySnapshot(TransactionId*nextXid)
872+
LogStandbySnapshot(void)
873873
{
874874
RunningTransactionsrunning;
875875
xl_standby_lock*locks;
@@ -898,8 +898,6 @@ LogStandbySnapshot(TransactionId *nextXid)
898898
LogCurrentRunningXacts(running);
899899
/* GetRunningTransactionData() acquired XidGenLock, we must release it */
900900
LWLockRelease(XidGenLock);
901-
902-
*nextXid=running->nextXid;
903901
}
904902

905903
/*

‎src/include/storage/standby.h

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -111,6 +111,6 @@ typedef RunningTransactionsData *RunningTransactions;
111111
externvoidLogAccessExclusiveLock(OiddbOid,OidrelOid);
112112
externvoidLogAccessExclusiveLockPrepare(void);
113113

114-
externvoidLogStandbySnapshot(TransactionId*nextXid);
114+
externvoidLogStandbySnapshot(void);
115115

116116
#endif/* STANDBY_H */

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp