Re: A question regarding LWLock in ProcSleep

From: Kenan Yao <kyao(at)pivotal(dot)io>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: A question regarding LWLock in ProcSleep
Date: 2015-12-22 03:41:26
Message-ID: CAO1BoPw2OhQjZ5e4qk2EaVpAFPsRyD81pHsn6yw0-goADZ62dA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Amit,

Thanks for the reply!

Yes, in LockAcquireExtended, after exiting WaitOnLock, there would be a
read access to proclock, however, since the lock has either been granted or
rejected by deadlock check, I can think of no possible concurrent write
access to the proclock, so is it really necessary to acquire the LWLock?

Thanks,
Kenan

On Fri, Dec 18, 2015 at 10:25 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
wrote:

> On Thu, Dec 17, 2015 at 1:51 PM, Kenan Yao <kyao(at)pivotal(dot)io> wrote:
>
>> Hi there,
>>
>> In function ProcSleep, after the process has been waken up, either with
>> lock granted or deadlock detected, it would re-acquire the lock table's
>> partition LWLock.
>>
>> The code episode is here:
>>
>> /*
>> * Re-acquire the lock table's partition lock. We have to do this to hold
>> * off cancel/die interrupts before we can mess with lockAwaited (else we
>> * might have a missed or duplicated locallock update).
>> */
>> LWLockAcquire(partitionLock, LW_EXCLUSIVE);
>>
>> /*
>> * We no longer want LockErrorCleanup to do anything.
>> */
>> lockAwaited = NULL;
>>
>> /*
>> * If we got the lock, be sure to remember it in the locallock table.
>> */
>> if (MyProc->waitStatus == STATUS_OK)
>> GrantAwaitedLock();
>>
>> /*
>> * We don't have to do anything else, because the awaker did all the
>> * necessary update of the lock table and MyProc.
>> */
>> return MyProc->waitStatus;
>>
>> ​
>> Questions are:
>>
>> (1) The comment says that "we might have a missed or duplicated locallock
>> update", in what cases would we hit this if without holding the LWLock?
>>
>> (2) The comment says "we have to do this to hold off cancel/die
>> interrupts", then:
>>
>> - why using LWLockAcquire instead of HOLD_INTERRUPTS directly?
>> - From the handler of SIGINT and SIGTERM, seems nothing serious would
>> be processed here, since no CHECK_FOR_INTERRUPS is called before releasing
>> this LWLock. Why we should hold off cancel/die interrupts here?
>>
>> (3) Before releasing this LWLock, the only share memory access is
>> MyProc->waitStatus; since the process has been granted the lock or removed
>> from the lock's waiting list because of deadlock, is it possible some other
>> processes would access this field? if not, then why we need LWLock here?
>> what does this lock protect?
>>
>>
> I think the other thing which needs protection of LWLock is
> access to proclock which is done in the caller
> (LockAcquireExtended).
>
>
>
>
> With Regards,
> Amit Kapila.
> EnterpriseDB: http://www.enterprisedb.com
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kenan Yao 2015-12-22 03:43:27 Re: A question regarding LWLock in ProcSleep
Previous Message Craig Ringer 2015-12-22 02:27:24 Re: SET SESSION AUTHORIZATION superuser limitation.