From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(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-03 10:16:40 |
Message-ID: | 20140303101640.GB23352@awork2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Albe Laurenz | 2014-03-03 10:37:55 | Re: GSoC proposal |
Previous Message | Andres Freund | 2014-03-03 10:08:42 | Re: Patch: show relation and tuple infos of a lock to acquire |