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

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: Patch: show relation and tuple infos of a lock to acquire
Дата
Msg-id CA+U5nMKbOK7_kWq7QWOfsLkDQqsKz-VhH+R2zAdP0crkpb27Gw@mail.gmail.com
обсуждение исходный текст
Ответ на 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  (Amit Kapila <amit.kapila16@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Atri Sharma
Дата:
Сообщение: Re: ALTER TABLE lock strength reduction patch is unsafe
Следующее
От: Joel Jacobson
Дата:
Сообщение: Re: plpgsql.warn_shadow