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.

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


---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

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

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

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

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