| From: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: CheckpointStartLock starvation |
| Date: | 2007-04-02 20:50:49 |
| Message-ID: | 46116CA9.7010800@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tom Lane wrote:
> Heikki Linnakangas <heikki(at)enterprisedb(dot)com> writes:
>> 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.
>
> What sort of "wait for finish" mechanism do you have in mind? While
> I've always thought CheckpointStartLock is a pretty ugly solution,
> I'm not sure the above is better.
I was thinking of XactLockTableWait.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2007-04-02 20:59:08 | Re: [PATCHES] Use non-deprecated APIs for dynloader/darwin.c |
| Previous Message | Mark Dilger | 2007-04-02 20:50:36 | Re: Bug in UTF8-Validation Code? |