From: | Amit kapila <amit(dot)kapila(at)huawei(dot)com> |
---|---|
To: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Resource Owner reassign Locks |
Date: | 2012-06-16 06:04:43 |
Message-ID: | 6C0B27F7206C9E4CA54AE035729E9C3828506276@szxeml509-mbx |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> I don't think so. C doesn't ref count its pointers.
You are right I have misunderstood.
> I don't think that lock tags have good human readable formats, and just
> a pointer dump probably wouldn't be much use when something that can
> never happen has happened. But I'll at least add a reference to the
> resource owner if this stays in.
I have checked in lock.c file for the message where lock tags have been used.
elog(ERROR, "lock %s on object %u/%u/%u is already held",
lockMethodTable->lockModeNames[lockmode],
lock->tag.locktag_field1, lock->tag.locktag_field2,
lock->tag.locktag_field3);
This can give more information about erroneous lock.
________________________________________
From: Jeff Janes [jeff(dot)janes(at)gmail(dot)com]
Sent: Saturday, June 16, 2012 3:21 AM
To: Amit kapila
Cc: pgsql-hackers
Subject: Re: [HACKERS] Resource Owner reassign Locks
On Mon, Jun 11, 2012 at 9:30 PM, Amit Kapila <amit(dot)kapila(at)huawei(dot)com> wrote:
>> Yes, that means the list has over-flowed. Once it is over-flowed, it
>> is now invalid for the reminder of the life of the resource owner.
> Don't we need any logic to clear the reference of locallock in owner->locks
> array.
I don't think so. C doesn't ref count its pointers.
> MAX_RESOWNER_LOCKS - How did you arrive at number 10 for it. Is there any
> specific reason for 10.
I instrumented the code to record the maximum number of locks held by
a resource owner, and report the max when it was destroyed. (That
code is not in this patch). During a large pg_dump, the vast majority
of the resource owners had maximum locks of 2, with some more at 4
and 6. Then there was one resource owner, for the top-level
transaction, at tens or hundreds of thousands (basically one for every
lockable object). There was little between 6 and this top-level
number, so I thought 10 was a good compromise, safely above 6 but not
so large that searching through the list itself was likely to bog
down.
Also, Tom independently suggested the same number.
>> Should it emit a FATAL rather than an ERROR? I thought ERROR was
>> sufficient to make the backend quit, as it is not clear how it could
>> meaningfully recover.
>
> I am not able to visualize any valid scenario in which it can happen unless
> some corruption happens.
> If this happens, user can close all statements and abort its transactions.
> According to me ERROR is okay. However in the message "Can't find lock to
> remove", it could be better,
> if there is information about resource owner and lock.
I think we might end up changing that entirely once someone more
familiar with the error handling mechanisms takes a look at it. I
don't think that lock tags have good human readable formats, and just
a pointer dump probably wouldn't be much use when something that can
never happen has happened. But I'll at least add a reference to the
resource owner if this stays in.
Thanks,
Jeff
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2012-06-16 06:11:25 | Re: libpq compression |
Previous Message | Amit kapila | 2012-06-16 05:58:42 | Re: Allow WAL information to recover corrupted pg_controldata |