Re: Patch: show relation and tuple infos of a lock to acquire

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Christian Kruse <christian(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Patch: show relation and tuple infos of a lock to acquire
Date: 2014-03-04 03:51:27
Message-ID: CAA4eK1JkcOxDAe1sRrrsOsv=qY7WF50znSwQJv6oG9pu1G5FUg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Mar 3, 2014 at 3:46 PM, Andres Freund <andres(at)2ndquadrant(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2014-03-04 04:01:50 Re: jsonb and nested hstore
Previous Message Peter Geoghegan 2014-03-04 03:39:45 Re: jsonb and nested hstore