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? It's currenty very
hard to debug those, just as it's hard to debug tuple/row locks caused
by explicit FOR SHARE/UPDATE/...
And if your argument is that the message might be displayed when a
explicit query cancel (statement timeout) instead of a deadlock_timeout
arrives, so what? It's still correct, and important information? After
all it seems to have waited long enough to get cancelled.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
