Horton

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

Amit Kapila <amit.kapila16@gmail.com>

View thread
From: Amit Kapila <amit.kapila16@gmail.com>
To: Dilip Kumar <dilipbalaut@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, 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-09T04:26:43Z
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 →

  1. Allow page lock to conflict among parallel group members.

  2. Allow relation extension lock to conflict among parallel group members.

  3. Add assert to ensure that page locks don't participate in deadlock cycle.

  4. Assert that we don't acquire a heavyweight lock on another object after

  5. Fix unsafe usage of strerror(errno) within ereport().

On Sat, Mar 7, 2020 at 9:19 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:

> On Sat, Mar 7, 2020 at 8:53 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >
> > 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?
>
> Basically,  if we can ensure that while holding the relation extension
> lock we will not wait for any other lock then we can ignore in the
> deadlock detection path so that we don't detect the false deadlock due
> to the group locking mechanism.  So if we are already holding the
> relation extension lock and trying to acquire the same lock-in same
> mode then it can never wait so this is safe.
>
> > 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.
>
> Right, we never need deadlock detection for this lock.  But, I think
> there are quite a few cases where we have multiple holds at the same
> time.  e.g, during RelationAddExtraBlocks, while holding the relation
> extension lock we try to update the block in FSM and FSM might need to
> add extra FSM block which will again try to acquire the same lock.
>
> But, I think the main reason for not converting it to an LWLocks is
> because Andres has a concern about inventing new lock mechanism as
> discuss upthread[1]
>
>
Right, that is one point and another is that if we go via the route of
converting it to LWLocks, then we also need to think of some solution for
page locks that are used in ginInsertCleanup.  However, if we go with the
approach being pursued [1] then the page locks will be handled in a similar
way as relation extension locks.

[1] -
https://www.postgresql.org/message-id/CAA4eK1%2BNjo%2BpnqSNi2ScKf0BcVBWWf37BrW-pykVSG0B0C5Qig%40mail.gmail.com

-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com