Re: Avoiding adjacent checkpoint records

On Wed, Jun 06, 2012 at 06:46:37PM -0400, Tom Lane wrote:
> I wrote:
> > Actually, it looks like there is an extremely simple way to handle this,
> > which is to move the call of LogStandbySnapshot (which generates the WAL
> > record in question) to before the checkpoint's REDO pointer is set, but
> > after we have decided that we need a checkpoint.
> 
> On further contemplation, there is a downside to that idea, which
> probably explains why the code was written as it was: if we place the
> XLOG_RUNNING_XACTS WAL record emitted during a checkpoint before rather
> than after the checkpoint's REDO point, then a hot standby slave
> starting up from that checkpoint won't process the XLOG_RUNNING_XACTS
> record.  That means its KnownAssignedXids machinery won't be fully
> operational until the master starts another checkpoint, which might be
> awhile.  So this could result in undesirable delay in hot standby mode
> becoming active.

Stupid question, but why are we not just setting a boolean variable in
shared memory if we WAL-write a non-XLOG_RUNNING_XACTS record, and only
checkpoint if that is true?

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +