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

On 4 March 2014 04:18, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> On Mon, Mar 3, 2014 at 3:38 PM, Andres Freund <andres(at)2ndquadrant(dot)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