Re: Patch: show relation and tuple infos of a lock to acquire
От | Andres Freund |
---|---|
Тема | Re: Patch: show relation and tuple infos of a lock to acquire |
Дата | |
Msg-id | 20140303101640.GB23352@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: Patch: show relation and tuple infos of a lock to acquire (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: Patch: show relation and tuple infos of a lock to acquire
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: