Re: Patch: show relation and tuple infos of a lock to acquire

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

In response to

Responses

Browse pgsql-hackers by date

  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