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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
