On Thu, Feb 27, 2014 at 4:14 PM, Christian Kruse
<christian@2ndquadrant.com> wrote:
> Hi,
>
> On 25/02/14 16:11, Robert Haas wrote:
>> On Mon, Feb 24, 2014 at 10:13 AM, Christian Kruse
>> <christian@2ndquadrant.com> wrote:
>> > To be honest, I don't like the idea of setting up this error context
>> > only for log_lock_wait messages. This sounds unnecessary complex to me
>> > and I think that in the few cases where this message doesn't add a
>> > value (and thus is useless) don't justify such complexity.
>>
>> 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.
I think using this context in more scenario's can do harm for certain cases
as mentioned upthread.
However I think the other reason for not putting in Detail is that for other
cases when this message is displayed, it already display similar info in
message as below:
LOG: process 4656 still waiting for ExclusiveLock on tuple (0,1) of relation 57
513 of database 12045 after 1046.000 ms
Also we might not have the appropriate info available at the place where
this message is generated unless we set global variable.
We have only information what LockTag has and for shared lock case it
doesn't have the info about tuple and relation.
>> 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.
>
>>
>> I wouldn't be inclined to dump the whole tuple under any
>> circumstances. That could be a lot more data than what you want
>> dumped in your log. The PK could already be somewhat unreasonably
>> large, but the whole tuple could be a lot more unreasonably large.
>
> 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.
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
