On Mon, Mar 3, 2014 at 3:46 PM, Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
