Re: We have got a serious problem with pg_clog/WAL synchronization

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.

In response to

Browse pgsql-hackers by date

  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