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
