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