Re: Patch: show relation and tuple infos of a lock to acquire - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Patch: show relation and tuple infos of a lock to acquire
Date
Msg-id CA+U5nMKbOK7_kWq7QWOfsLkDQqsKz-VhH+R2zAdP0crkpb27Gw@mail.gmail.com
Whole thread Raw
In response to Re: Patch: show relation and tuple infos of a lock to acquire  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Patch: show relation and tuple infos of a lock to acquire  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
On 4 March 2014 04:18, Amit Kapila <amit.kapila16@gmail.com> wrote:
> On Mon, Mar 3, 2014 at 3:38 PM, Andres Freund <andres@2ndquadrant.com> wrote:
>> On 2014-02-28 20:55:20 +0530, Amit Kapila wrote:
>>> On Thu, Feb 27, 2014 at 4:14 PM, Christian Kruse
>>> > Well, as I already stated: we don't. I copied the behavior we use in
>>> > CHECK constraints (ExecBuildSlotValueDescription()).
>>>
>>> I think now more people are of opinion that displaying whole tuple is
>>> not useful. I believe it is good to go ahead by displaying just primary key
>>> for this case and move ahead.
>>
>> The patch does not, and has never, printed the full tuple. What it does
>> is copying the behaviour of printing the tuple for check constraint
>> violations, which is truncating the tuple after a certain length.
>
> I know that patch truncates the values if they are greater than certain
> length (30), but the point is why it is not sufficient to have tuple location
> (and primary key if available) which uniquely identifies any tuple?

The patch follows a pattern established elsewhere, so arguing for this
change would be a change in existing behaviour that is outside the
scope of this patch. Please raise a new thread if you wish that
change, especially since it is opposed here.

This patch is small, but adds important functionality for diagnosing
user's locking problems.

If you have alterations to the patch please list them concisely so
people can understand them and progress towards getting this committed
or rejected. Thanks.

-- Simon Riggs                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: Atri Sharma
Date:
Subject: Re: ALTER TABLE lock strength reduction patch is unsafe
Next
From: Joel Jacobson
Date:
Subject: Re: plpgsql.warn_shadow