Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager
Date
Msg-id CA+Tgmoa=f94zhAayi7JZxC_545uBBBOkzvD7J4USnqJqu-boyA@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager  (Dilip Kumar <dilipbalaut@gmail.com>)
Responses Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
On Fri, Mar 6, 2020 at 11:27 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
> I think instead of the flag we need to keep the counter because we can
> acquire the same relation extension lock multiple times.  So
> basically, every time we acquire the lock we can increment the counter
> and while releasing we can decrement it.   During an error path, I
> think it is fine to set it to 0 in CommitTransaction/AbortTransaction.
> But, I am not sure that we can set to 0 or decrement it in
> AbortSubTransaction because we are not sure whether we have acquired
> the lock under this subtransaction or not.

I think that CommitTransaction, AbortTransaction, and friends have
*zero* business touching this. I think the counter - or flag - should
track whether we've got a PROCLOCK entry for a relation extension
lock. We either do, or we do not, and that does not change because of
anything have to do with the transaction state. It changes because
somebody calls LockRelease() or LockReleaseAll().

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: adding partitioned tables to publications
Next
From: Euler Taveira
Date:
Subject: Re: Restore replication settings when modifying a field type