| Lists: | pgsql-patches |
|---|
| From: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
|---|---|
| To: | Patches <pgsql-patches(at)postgresql(dot)org> |
| Subject: | Fix CheckpointStartLock starvation |
| Date: | 2007-04-03 12:49:54 |
| Message-ID: | 46124D72.6090601@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Lists: | pgsql-patches |
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
| Attachment | Content-Type | Size |
|---|---|---|
| eliminate_checkpointstartlock.patch | text/x-diff | 17.3 KB |
| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
| Cc: | Patches <pgsql-patches(at)postgresql(dot)org> |
| Subject: | Re: Fix CheckpointStartLock starvation |
| Date: | 2007-04-03 16:59:44 |
| Message-ID: | 9715.1175619584@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Lists: | pgsql-patches |
Heikki Linnakangas <heikki(at)enterprisedb(dot)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
| From: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Patches <pgsql-patches(at)postgresql(dot)org> |
| Subject: | Re: Fix CheckpointStartLock starvation |
| Date: | 2007-04-03 18:03:58 |
| Message-ID: | 4612970E.7050207@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Lists: | pgsql-patches |
Tom Lane wrote:
> Heikki Linnakangas <heikki(at)enterprisedb(dot)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