Re: ProcArrayLock contention - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: ProcArrayLock contention
Date
Msg-id CA+U5nMKNUfFks8a52N5UJa-NLC5hzLM-Cqx4besSmJSYhymE3A@mail.gmail.com
Whole thread Raw
In response to ProcArrayLock contention  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Tue, Nov 8, 2011 at 4:52 AM, Robert Haas <robertmhaas@gmail.com> wrote:

> With 80 clients (but not 32 or fewer), I occasionally get the
> following error:
>
> ERROR:  t_xmin is uncommitted in tuple to be updated
>
> So it seems that there's some way in which this locking is actually
> incorrect, though I'm not seeing what it is at the moment.  Either
> that, or there's some bug in the existing code that happens to be
> exposed by this change.

The semantics of shared locks is that they jump the existing queue, so
this patch allows locks to be held in sequences not previously seen
when using exclusive locks.

For me, the second kind of lock should queue up normally, but then be
released en masse when possible. So queue like an exclusive, but wake
like a shared. Vaguely remember shared_queued.v1.patch

That can then produce flip-flop lock parties. A slight problem there
is that when shared locks queue they don't all queue together, a
problem which the other patch addresses, written long ago.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Attachment

pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: synchronous commit vs. hint bits
Next
From: Simon Riggs
Date:
Subject: Re: heap vacuum & cleanup locks