On Sun, 2007-04-08 at 17:02 +0100, Simon Riggs wrote: > My concern was this: > > If we flush the currently outstanding deferred transactions then that > doesn't guarantee they have all reached the clog. Previously, a deferred > transaction would not release the CheckpointStartLock until after the > clog had been updated. > > If we wait for all currently inCommit transactions to end this will > cover all deferred transactions also. So I think I just need to flush > deferred transactions prior to the wait and this will be valid. Would > you agree?
I'm good with this now, sorry for the noise. >From the existing code in CreateCheckpoint, just need to add a background flush immediately prior to the newly added waits. That would replace what I've got in the current patch where I hold the lock across the calculation the WAL insert pointer for the checkpoint which was too safe - there is no need for prior WAL to be flushed at that point. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
