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

From: Kenneth Marshall <ktm(at)it(dot)is(dot)rice(dot)edu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Kenneth Marshall <ktm(at)is(dot)rice(dot)edu>, pgsql-hackers(at)postgreSQL(dot)org, xu(at)cs(dot)wisc(dot)edu
Subject: Re: Re: We have got a serious problem with pg_clog/WAL synchronization
Date: 2004-08-12 17:03:36
Message-ID: 20040812170336.GA11862@it.is.rice.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

On Thu, Aug 12, 2004 at 09:58:56AM -0400, Tom Lane wrote:
> Kenneth Marshall <ktm(at)is(dot)rice(dot)edu> writes:
> > Would it be possible to use a latch + version number in
> > this case to minimize this problem by allowing all but the checkpoint to
> > perform a read-only action on the latch?
>
> How would a read-only action work to block out the checkpoint?
>
> More generally, though, this lock is hardly the one I'd be most
> concerned about in an SMP situation. It's only taken once per
> transaction, while there are others that may be taken many times.
> (At least two of these, the WALInsertLock and the lock on shared
> pg_clog, will need to be taken again in the process of recording
> transaction commit.)
>
> What I'd most like to find is a way to reduce contention for the
> BufMgrLock --- there are at least some behavioral patterns in which
> that is demonstrably a dominant cost. See past discussions in the
> archives ("context swap storm" should find you some recent threads).
>
> regards, tom lane
>

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.

Ken

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2004-08-12 17:13:46 Re: Re: We have got a serious problem with pg_clog/WAL synchronization
Previous Message Robby Russell 2004-08-12 16:57:06 Re: upgrading in RH 8

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2004-08-12 17:13:46 Re: Re: We have got a serious problem with pg_clog/WAL synchronization
Previous Message Henry 2004-08-12 15:55:35 Referencing OLD/NEW Rows on Trigger Definition