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

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: Patch: show relation and tuple infos of a lock to acquire
Дата
Msg-id CAA4eK1+xkPX4F2S3YSwouVMhJ0OrPyzzEM0UY9YP_h8pJfPcfA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Patch: show relation and tuple infos of a lock to acquire  (Christian Kruse <christian@2ndquadrant.com>)
Ответы Re: Patch: show relation and tuple infos of a lock to acquire  (Andres Freund <andres@2ndquadrant.com>)
Список pgsql-hackers
On Thu, Feb 27, 2014 at 4:14 PM, Christian Kruse
<christian@2ndquadrant.com> wrote:
> On 25/02/14 16:11, Robert Haas wrote:
>> Reading this over, I'm not sure I understand why this is a CONTEXT at
>> all and not just a DETAIL for the particular error message that it's
>> supposed to be decorating.  Generally CONTEXT should be used for
>> information that will be relevant to all errors in a given code path,
>> and DETAIL for extra information specific to a particular error.
>
> Because there is more than one scenario where this context is useful,
> not just log_lock_wait messages.
>
>> If we're going to stick with CONTEXT, we could rephrase it like this:
>>
>> CONTEXT: while attempting to lock tuple (1,2) in relation with OID 3456
>>
>> or when the relation name is known:
>>
>> CONTEXT: while attempting to lock tuple (1,2) in relation "public"."foo"
>
> Accepted. Patch attached.

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.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: proposal: new long psql parameter --on-error-stop
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: proposal: new long psql parameter --on-error-stop