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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Kenneth Marshall <ktm(at)is(dot)rice(dot)edu>
Cc: 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 13:58:56
Message-ID: 28362.1092319136@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Christopher Kings-Lynne 2004-08-12 14:07:45 Re: [GENERAL] How to know which queries are to be optimised?
Previous Message Tom Lane 2004-08-12 13:39:37 Re: [pgsql-hackers-win32] error moving table to tablespace (8.0 beta win32 )

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2004-08-12 15:32:41 Re: Turkish downcasting in PL/pgSQL
Previous Message Tom Lane 2004-08-12 13:42:05 Re: pg_restore (libpq? parser?) bug in 8