CheckpointStartLock starvation

I'm seeing a problem on my benchmark machine: checkpoints stop happening
after the ramp-up period.

It looks like the bgwriter gets starved waiting on the
CheckpointStartLock. The CheckpointStartLock is held in shared mode over
an XLogFlush when committing, which on an extremely busy system like a
benchmark is always long enough to have a new transaction to acquire the
CheckpointStartLock again.

I'm running another test with more logging to confirm that's what's
happening, but I'm pretty sure that's it...

As a proposed fix, instead of acquiring the CheckpointStartLock in
RecordTransactionCommit, we set a flag in MyProc saying "commit in
progress". Checkpoint will scan through the procarray and make note of
any commit in progress transactions, after computing the new redo record
ptr, and wait for all of them to finish before flushing clog.

Unless someone has a better idea, I'll write a patch to do the above.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com