Re: ProcArrayLock contention

On Tue, Nov 8, 2011 at 4:52 AM, Robert Haas <robertmhaas(at)gmail(dot)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