Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
On a busy system, checkpoint could be starved while queuing for the CheckpointStartLock. To avoid that, get rid of CheckpointStartLock and instead set a flag in PGPROC struct when a commit starts. After computing the REDO ptr, checkpoint waits for all backends that had that flag set to finish their commits. This eliminates the same race condition the CheckpointStartLock was there for, without the risk of starvation.


Applied with some revisions --- I did not see the point of forcing
checkpoint to wait till the transaction was fully out of its commit;
we only need it to wait till clog is updated.

Thanks! I'll rerun my test with this.

There was no particular reason to delay, but I figured it doesn't really matter either way since checkpoints are not in a hurry.

The procarray code seemed overly complicated too.

Yeah, it was a bit ugly. I wanted to doing the O(n^2) looping while holding the ProcArrayLock. I doubt it's a problem in practice since it's only done during a checkpoint and n should be small, but I'll stick to that excuse.

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

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Reply via email to