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

Robert Haas <robertmhaas@gmail.com>

From: Robert Haas <robertmhaas@gmail.com>

To: Masahiko Sawada <sawada.mshk@gmail.com>

Cc: Tom Lane <tgl@sss.pgh.pa.us>, Thomas Munro <thomas.munro@enterprisedb.com>, Amit Kapila <amit.kapila16@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>

Date: 2017-12-01T20:32:00Z

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 Fri, Dec 1, 2017 at 1:28 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> [ lots of minor comments ]

When I took a break from sitting at the computer, I realized that I
think this has a more serious problem: won't it permanently leak
reference counts if someone hits ^C or an error occurs while the lock
is held?  I think it will -- it probably needs to do cleanup at the
places where we do LWLockReleaseAll() that includes decrementing the
shared refcount if necessary, rather than doing cleanup at the places
we release heavyweight locks.

I might be wrong about the details here -- this is off the top of my head.

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