Skip site navigation (1) Skip section navigation (2)

pgsql: Don't advance checkPoint.nextXid near the end of a checkpointse

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-committers(at)postgresql(dot)org
Subject: pgsql: Don't advance checkPoint.nextXid near the end of a checkpointse
Date: 2012-12-02 20:21:11
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-committers
Don't advance checkPoint.nextXid near the end of a checkpoint sequence.

This reverts commit c11130690d6dca64267201a169cfb38c1adec5ef in favor of
actually fixing the problem: namely, that we should never have been
modifying the checkpoint record's nextXid at this point to begin with.
The nextXid should match the state as of the checkpoint's logical WAL
position (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 the
same nextXid shown in the XLOG_RUNNING_XACTS record just emitted by
LogStandbySnapshot, as any replay operation will already have adopted
that 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 the
instant 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 checkpoint
being in progress at any given instant.)

Diagnosed by me and independently by Andres Freund.  Back-patch to all
branches supporting hot standby.



Modified Files
src/backend/access/transam/xlog.c |   11 +----------
src/backend/storage/ipc/standby.c |    4 +---
src/include/storage/standby.h     |    2 +-
3 files changed, 3 insertions(+), 14 deletions(-)

pgsql-committers by date

Next:From: Simon RiggsDate: 2012-12-02 20:57:17
Subject: pgsql: Reduce scope of changes for COPY FREEZE.
Previous:From: Simon RiggsDate: 2012-12-02 19:48:50
Subject: pgsql: Rearrange storage of data in xl_running_xacts.

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group