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

From Simon Riggs
Subject Re: Patch: show relation and tuple infos of a lock to acquire
Date
Msg-id CA+U5nMJ34My-EoXsT+Z90faB0O0K9HdT6iWDZRzfp22Ry4i_Vw@mail.gmail.com
Whole thread Raw
In response to Re: Patch: show relation and tuple infos of a lock to acquire  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Patch: show relation and tuple infos of a lock to acquire
List pgsql-hackers
On 31 December 2013 16:36, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Simon Riggs <simon@2ndQuadrant.com> writes:
>> On 31 December 2013 09:12, Christian Kruse <christian@2ndquadrant.com> wrote:
>>> Output with patch:
>>>
>>> LOG:  process 24774 acquired ShareLock on transaction 696 after 11688.720 ms
>>> CONTEXT:  relation name: foo (OID 16385)
>>> tuple (ctid (0,1)): (1)
>
>> That is useful info.
>
>> I think the message should be changed to say this only, without a context line
>
>> LOG:  process 24774 acquired ShareLock on relation "foo" (OID 16385)
>> tuple (0,1) after 11688.720 ms
>
>> My reason is that pid 24774 was waiting for a *tuple lock* and it was
>> eventually granted, so thats what it should say.
>
> No, that wasn't what it was waiting for, and lying to the user like that
> isn't going to make things better.

"Like that" is ambiguous and I don't understand you or what you are
objecting to.

When we run SELECT ... FOR SHARE we are attempting to lock rows. Why
is the transaction we are waiting for important when we wait to lock
rows, but when we wait to lock relations it isn't?

-- Simon Riggs                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Patch: show relation and tuple infos of a lock to acquire
Next
From: Tom Lane
Date:
Subject: Re: fix_PGSTAT_NUM_TABENTRIES_macro patch