On Tue, Nov 8, 2011 at 4:52 AM, Robert Haas <robertmh...@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
shared_lwlock.v1.patch
Description: Binary data
shared_queued.v1.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
