On Tue, Dec 31, 2013 at 1:12 AM, Christian Kruse <christ...@2ndquadrant.com> wrote: > I created a patch improving the log_lock_wait messages by adding > relation infos (name and OID) as well as tuple infos (if present – > ctid and, if available, the tuple itself) in the context.
I think that this is a worthwhile effort, but like Tom I don't think that it's universally true that these waiters are waiting on a tuple lock. Most obviously, the XactLockTableWait() call you've modified within nbtinsert.c is not. In actuality, it's waiting on what I informally refer to as a "value lock" for a value being inserted into a unique index. Unlike the tuple locking code, a LockTuple() call in advance of the XactLockTableWait() call, to arbitrate ordering, is not present. No tuple is locked at all. ISTM that you should be printing just the value and the unique index there, and not any information about the tuple proper. Doing any less could be highly confusing. You should do an analysis of where this kind of exception applies. For better direction about where that new infrastructure ought to live, you might find some useful insight from commit 991f3e5ab3f8196d18d5b313c81a5f744f3baaea. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
