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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
