From: | "Min Xu (Hsu)" <mxu(at)cae(dot)wisc(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org, OKADA Satoshi <okada(dot)satoshi(at)lab(dot)ntt(dot)co(dot)jp> |
Subject: | Re: We have got a serious problem with pg_clog/WAL synchronization |
Date: | 2004-08-11 15:35:02 |
Message-ID: | 411A3CA6.6060800@cae.wisc.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
>
>Unfortunately, there isn't any pre-existing lock that will serve.
>A transaction that is between XLogInsert'ing its COMMIT record and
>updating the shared pg_clog data area does not hold any lock that
>could be used to prevent a checkpoint from starting. (Or it didn't
>until yesterday's patch, anyway.)
>
>I looked briefly at reorganizing the existing code so that we'd do the
>COMMIT XLogInsert while we're holding lock on the shared pg_clog data,
>which would solve the problem without adding any new lock acquisition.
>But this seemed extremely messy to do. Also it would be optimizing
>transaction commit at the cost of pessimizing other uses of pg_clog,
>which might have to wait longer to get at the shared data. Adding the
>new lock has the advantage that we can be sure it's not blocking
>anything we don't want it to block.
>
>Thanks for thinking about the problem though ...
>
>
You are welcome.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-08-11 15:36:59 | Re: fsync, fdatasync, open_sync, and open_datasync, -- Linux insanity |
Previous Message | Tom Lane | 2004-08-11 15:25:58 | Re: We have got a serious problem with pg_clog/WAL synchronization |