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

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>

To: Dilip Kumar <dilipbalaut@gmail.com>

Cc: Amit Kapila <amit.kapila16@gmail.com>, Mahendra Singh Thalor <mahi6run@gmail.com>, Andres Freund <andres@anarazel.de>, Robert Haas <robertmhaas@gmail.com>, 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-07T15:23:39Z

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

Dilip Kumar <dilipbalaut@gmail.com> writes:
> I think instead of the flag we need to keep the counter because we can
> acquire the same relation extension lock multiple times.

Uh ... what?  How would that not be broken usage on its face?

I continue to think that we'd be better off getting all of this
out of the heavyweight lock manager.  There is no reason why we
should need deadlock detection, or multiple holds of the same
lock, or pretty much anything that LWLocks don't give you.

			regards, tom lane