Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager

Robert Haas <robertmhaas@gmail.com>

From: Robert Haas <robertmhaas@gmail.com>

To: Amit Kapila <amit.kapila16@gmail.com>

Cc: Mahendra Singh Thalor <mahi6run@gmail.com>, Dilip Kumar <dilipbalaut@gmail.com>, Andres Freund <andres@anarazel.de>, Tom Lane <tgl@sss.pgh.pa.us>, Masahiko Sawada <masahiko.sawada@2ndquadrant.com>, Masahiko Sawada <sawada.mshk@gmail.com>, Michael Paquier <michael@paquier.xyz>, Mithun Cy <mithun.cy@enterprisedb.com>, Thomas Munro <thomas.munro@enterprisedb.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>

Date: 2020-03-06T17:49:21Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Allow page lock to conflict among parallel group members.
- 3ba59ccc896e 13.0 landed
Allow relation extension lock to conflict among parallel group members.
- 85f6b49c2c53 13.0 landed
Add assert to ensure that page locks don't participate in deadlock cycle.
- 72e78d831ab5 13.0 landed
Assert that we don't acquire a heavyweight lock on another object after
- 15ef6ff4b985 13.0 landed
Fix unsafe usage of strerror(errno) within ereport().
- 81256cd05f07 11.0 cited

On Thu, Mar 5, 2020 at 11:45 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> I think we can keep such a flag in TopTransactionState.   We free such
> locks after the work is done (except during error where we free them
> at transaction abort) rather than at transaction commit, so one might
> say it is better not to associate with transaction state, but not sure
> if there is other better place.  Do you have any suggestions?

I assumed it would be a global variable in lock.c.  lock.c has got to
know when any lock is required or released, so I don't know why we
need to involve xact.c in the bookkeeping.

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