Re: Patch: show relation and tuple infos of a lock to acquire

From: Peter Geoghegan <pg(at)heroku(dot)com>
To: Christian Kruse <christian(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Patch: show relation and tuple infos of a lock to acquire
Date: 2013-12-31 21:56:53
Message-ID: CAM3SWZRRUHOYjGay7fM_EBDx+kPOyYYzE4YGECruzpe7Xu-=kw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Dec 31, 2013 at 1:12 AM, Christian Kruse
<christian(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Adrian Klaver 2013-12-31 22:02:59 Re: pg_upgrade & tablespaces
Previous Message Joseph Kregloh 2013-12-31 21:51:22 Re: pg_upgrade & tablespaces