> 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.ja...@gmail.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.kap...@huawei.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 -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers