Horton

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

Andres Freund <andres@anarazel.de>

View thread
From: Andres Freund <andres@anarazel.de>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Mithun Cy <mithun.cy@enterprisedb.com>, Masahiko Sawada <sawada.mshk@gmail.com>, 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: 2018-03-01T20:40:59Z
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 2018-03-01 15:37:17 -0500, Robert Haas wrote:
> On Thu, Mar 1, 2018 at 2:17 PM, Andres Freund <andres@anarazel.de> wrote:
> >> However, if we take the position that no hash collision probability is
> >> low enough and that we must eliminate all chance of false collisions,
> >> except perhaps when the table is full, then we have to make this
> >> locking mechanism a whole lot more complicated.  We can no longer
> >> compute the location of the lock we need without first taking some
> >> other kind of lock that protects the mapping from {db_oid, rel_oid} ->
> >> {memory address of the relevant lock}.
> >
> > Hm, that's not necessarily true, is it? Wile not trivial, it also
> > doesn't seem impossible?
> 
> You can't both store every lock at a fixed address and at the same
> time put locks at a different address if the one they would have used
> is already occupied.

Right, but why does that require a lock?

Greetings,

Andres Freund