Re: Patch: show relation and tuple infos of a lock to acquire - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Patch: show relation and tuple infos of a lock to acquire
Date
Msg-id CAM3SWZRRUHOYjGay7fM_EBDx+kPOyYYzE4YGECruzpe7Xu-=kw@mail.gmail.com
Whole thread Raw
In response to Patch: show relation and tuple infos of a lock to acquire  (Christian Kruse <christian@2ndQuadrant.com>)
Responses Re: Patch: show relation and tuple infos of a lock to acquire  (Christian Kruse <christian@2ndquadrant.com>)
Re: Patch: show relation and tuple infos of a lock to acquire  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
On Tue, Dec 31, 2013 at 1:12 AM, Christian Kruse
<christian@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



pgsql-hackers by date:

Previous
From: Mark Dilger
Date:
Subject: Re: proposal: multiple read-write masters in a cluster with wal-streaming synchronization
Next
From: Tom Lane
Date:
Subject: What exactly is drop-index-concurrently-1.spec trying to test?