Re: Contention on LWLock buffer_content, due to SHARED lock(?)

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Jens-Wolfhard Schicke-Uffmann <drahflow(at)gmx(dot)de>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Contention on LWLock buffer_content, due to SHARED lock(?)
Date: 2019-12-10 18:07:05
Message-ID: 20191210180705.GA12733@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2019-Dec-10, Andres Freund wrote:

> > The hard part would probably be to ensure that an
> > attempt to obtain an EXCLUSIVE lock would finally succeed against a
> > SHARE lock held by "everyone".
>
> Note that this is a seriously complicated area of the code. It's very
> easy to create new bugs that aren't easily testable. I think we'd need a
> very convincing use-case for improvements around the problem you outline
> and relatively simple solution, to counter stability concerns.

I'd rather have the ability to mark a table READ ONLY (or similar).
Then any FK references can skip the row locks altogether. For the rare
cases where you need to modify the referenced table, have it marked READ
WRITE, and any row locks are registered normally from that point on,
until you set it back to READ ONLY again.

--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2019-12-10 18:08:21 Re: xact_start for walsender & logical decoding not updated
Previous Message Robert Haas 2019-12-10 18:07:02 allowing broader use of simplehash