Fix CheckpointStartLock starvation

Heikki Linnakangas <heikki@enterprisedb.com> 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. The procarray code
seemed overly complicated too.

regards, tom lane

Tom Lane wrote:

Heikki Linnakangas <heikki@enterprisedb.com> 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