From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
---|---|
To: | Amit Kapila <amit(dot)kapila(at)huawei(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Resource Owner reassign Locks |
Date: | 2012-06-11 15:21:57 |
Message-ID: | CAMkU=1yL2UJEDKza9cdEDRYjRqZB3F_8+m_a=TTr_eUiGgoAZQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Jun 10, 2012 at 11:28 PM, Amit Kapila <amit(dot)kapila(at)huawei(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2012-06-11 15:24:37 | Re: pg_receivexlog and feedback message |
Previous Message | Atri Sharma | 2012-06-11 15:17:28 | Re: 9.2 final |