On Thu, 2009-02-05 at 21:54 +0200, Heikki Linnakangas wrote: > - If bgwriter is performing a restartpoint when recovery ends, the > startup checkpoint will be queued up behind the restartpoint. And since > it uses the same smoothing logic as checkpoints, it can take quite some > time for that to finish. The original patch had some code to hurry up > the restartpoint by signaling the bgwriter if > LWLockConditionalAcquire(CheckPointLock) fails, but there's a race > condition with that if a restartpoint starts right after that check. We > could let the bgwriter do the checkpoint too, and wait for it, but > bgwriter might not be running yet, and we'd have to allow bgwriter to > write WAL while disallowing it for all other processes, which seems > quite complex. Seems like we need something like the > LWLockConditionalAcquire approach, but built into CreateCheckPoint to > eliminate the race condition
Seems straightforward? Hold the lock longer. > - If you perform a fast shutdown while startup process is waiting for > the restore command, startup process sometimes throws a FATAL error > which leads escalates into an immediate shutdown. That leads to > different messages in the logs, and skipping of the shutdown > restartpoint that we now otherwise perform. Sometimes? > - It's not clear to me if the rest of the xlog flushing related > functions, XLogBackgroundFlush, XLogNeedsFlush and XLogAsyncCommitFlush, > need to work during recovery, and what they should do. XLogNeedsFlush should always return false InRecoveryProcessingMode(). The WAL is already in the WAL files, not in wal_buffers anymore. XLogAsyncCommitFlush should contain Assert(!InRecoveryProcessingMode()) since it is called during a VACUUM FULL only. XLogBackgroundFlush should never be called during recovery because the WALWriter is never active in recovery. That should just be documented. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers