Re: ProcArrayLock contention

On Tue, Nov 8, 2011 at 2:24 AM, YAMAMOTO Takashi <yamt(at)mwd(dot)biglobe(dot)ne(dot)jp> wrote:
> latestCompletedXid got backward due to concurrent updates
> and it fooled TransactionIdIsInProgress?

Ah ha! I bet that's it.

I think this could be avoided by a more sophisticated locking scheme.
Instead of waking up all the people trying to do
ProcArrayEndTransaction() and letting them all run simultaneously,
wake up one of them. That one guy goes and clears all the XID fields
and updates latestCompletedXid, and then wakes up all the others (who
now don't even need to reacquire the spinlock to "release" the lock,
because they never really held it in the first place, but yet the work
they needed done is done).

The trick is to make something like that work within the confines of
the LWLock mechanism. It strikes me that we have a number of places
in the system where it would be useful to leverage the queuing and
error handling facilities that the lwlock mechanism provides, but have
different rules for handling lock conflicts - either different lock
modes, or request combining, or whatever. lwlock.c is an awfully big
chunk of code to cut-and-paste if you need an lwlock with three modes,
or some primitive that has behavior similar to an lwlock overall but
with some differences in detail. I wonder if there's a way that we
could usefully refactor things to make that sort of thing easier.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company