Re: Re: We have got a serious problem with pg_clog/WAL synchronization - Mailing list pgsql-hackers

From Kenneth Marshall
Subject Re: Re: We have got a serious problem with pg_clog/WAL synchronization
Date
Msg-id 20040812182517.GB11862@it.is.rice.edu
Whole thread Raw
In response to Re: Re: We have got a serious problem with pg_clog/WAL synchronization  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Re: We have got a serious problem with pg_clog/WAL synchronization
List pgsql-hackers
On Thu, Aug 12, 2004 at 01:13:46PM -0400, Tom Lane wrote:
> Kenneth Marshall <ktm@is.rice.edu> writes:
> > On Thu, Aug 12, 2004 at 09:58:56AM -0400, Tom Lane wrote:
> >> How would a read-only action work to block out the checkpoint?
> 
> > The latch+version number is use by the checkpoint process. The
> > other processes can do a read of the latch to determine if it has
> > been set. This does not cause a cache invalidation hit. If the
> > latch is set, the competing processes read until it has been
> > cleared and the version updated. This makes the general case of
> > no checkpoint not incur a write and the consequent cache-line
> > invalidation and reload by all processors on an SMP system.
> 
> Except that reading the latch and finding it clear offers no guarantee
> that a checkpoint isn't about to start.  The problem is that we are
> performing two separate actions (write a COMMIT xlog record and update
> transaction status in clog) and we have to prevent a checkpoint from
> starting in between those actions.  I don't see that there's any way to
> do that with a read-only latch.
> 
>             regards, tom lane

Yes, you are correct. I missed that part of the previous thread. When
I saw "exclusive lock" I thought latch since that is what I am investigating
to solve other performance issues that I am addressing.

Ken


pgsql-hackers by date:

Previous
From: henryyipca@yahoo.ca (Henry)
Date:
Subject: Referencing OLD/NEW Rows on Trigger Definition
Next
From: Chris Browne
Date:
Subject: Asserting existing key to be primary