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

From Amit Kapila
Subject Re: Patch: show relation and tuple infos of a lock to acquire
Date
Msg-id CAA4eK1+xkPX4F2S3YSwouVMhJ0OrPyzzEM0UY9YP_h8pJfPcfA@mail.gmail.com
Whole thread Raw
In response to Re: 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  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
On Thu, Feb 27, 2014 at 4:14 PM, Christian Kruse
<christian@2ndquadrant.com> wrote:
> On 25/02/14 16:11, Robert Haas wrote:
>> Reading this over, I'm not sure I understand why this is a CONTEXT at
>> all and not just a DETAIL for the particular error message that it's
>> supposed to be decorating.  Generally CONTEXT should be used for
>> information that will be relevant to all errors in a given code path,
>> and DETAIL for extra information specific to a particular error.
>
> Because there is more than one scenario where this context is useful,
> not just log_lock_wait messages.
>
>> If we're going to stick with CONTEXT, we could rephrase it like this:
>>
>> CONTEXT: while attempting to lock tuple (1,2) in relation with OID 3456
>>
>> or when the relation name is known:
>>
>> CONTEXT: while attempting to lock tuple (1,2) in relation "public"."foo"
>
> Accepted. Patch attached.

With new patch, the message while updating locked rows will be displayed
as below:

LOG:  process 364 still waiting for ShareLock on transaction 678 after
1014.000ms
CONTEXT:  while attempting to lock tuple (0,2) with values (2) in relation "publ
ic"."t1" of database postgres

LOG:  process 364 acquired ShareLock on transaction 678 after 60036.000 ms
CONTEXT:  while attempting to lock tuple (0,2) with values (2) in relation "publ
ic"."t1" of database postgres

Now I am not sure, if the second message is an improvement, as what it sounds
is "while attempting to lock tuple, it got shared lock on
transaction'. If you, Robert
or other feels it is okay, then we can retain it as it is in patch
else I think either
we need to rephrase it or may be try with some other way (global variable) such
that it appears only for required case. I feel the way Robert has
suggested i.e to
make it as Detail of particular message (we might need to use global variable to
pass certain info) is better way and will have minimal impact on the cases where
this additional information needs to be displayed.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: proposal: new long psql parameter --on-error-stop
Next
From: Pavel Stehule
Date:
Subject: Re: proposal: new long psql parameter --on-error-stop