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 CAA4eK1JkcOxDAe1sRrrsOsv=qY7WF50znSwQJv6oG9pu1G5FUg@mail.gmail.com
Whole thread Raw
In response to Re: Patch: show relation and tuple infos of a lock to acquire  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
On Mon, Mar 3, 2014 at 3:46 PM, Andres Freund <andres@2ndquadrant.com> wrote:
> On 2014-03-01 13:29:18 +0530, Amit Kapila wrote:
>> 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.
>
> I really don't understand the origins of your arguments here. Why
> shouldn't a row lock caused by an UPDATE be relevant?

The point I am trying to say is about below part of statement in
Context message:
"while attempting to lock tuple (0,2) ".

In above situation, we are actually trying to acquire a lock on transaction to
operate on a tuple, so I think it will be better to rephrase it (may be by using
'operate on' instead of 'lock').


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



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: jsonb and nested hstore
Next
From: Peter Geoghegan
Date:
Subject: Re: jsonb and nested hstore