> 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.
MAX_RESOWNER_LOCKS - How did you arrive at number 10 for it. Is there any specific reason for 10. > 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. -----Original Message----- From: Jeff Janes [mailto:jeff.ja...@gmail.com] Sent: Monday, June 11, 2012 8:52 PM To: Amit Kapila Cc: pgsql-hackers Subject: Re: [HACKERS] Resource Owner reassign Locks On Sun, Jun 10, 2012 at 11:28 PM, Amit Kapila <amit.kap...@huawei.com> wrote: > I have few doubts regarding logic of ResourceOwnerRememberLock() and > ResourceOwnerForgetLock(): > 1. In function ResourceOwnerRememberLock(), when lock count is > MAX_RESOWNER_LOCKS, it will not add the lock to lock array but increment the > count to make it 11. 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. At one time I used simpler logic that stored the last lock even though it could never be accessed, but I didn't like that and changed it to three-valued logic: already over-flowed, just about to over-flow (do not store, but still increment), and normal (store and increment). I guess I could add a macro to test for overflow, rather than explicitly comparing nlocks to MAX_RESOWNER_LOCKS, but I would either need another macro for the "Not yet overflowed, but soon to be", or would still need to do a manual test in that one spot. > Now in ResourceOwnerForgetLock(), it cannot enter the if loop until the > count is <= MAX_RESOWNER_LOCKS. So how it will forget the lock. When it comes time to release or reassign, it will fall back to the original behavior of looking through the local lock table. > > 2. ResourceOwnerForgetLock(), it decrements the lock count before removing, > so incase it doesn't find the lock in lockarray, the count will be > decremented inspite the array still contains the same number of locks. 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. Cheers, Jeff -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
