Re: Resource Owner reassign Locks

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

In response to

Responses

Browse pgsql-hackers by date

  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