Re: BufferAlloc: don't take two simultaneous locks - Mailing list pgsql-hackers

From Robert Haas
Subject Re: BufferAlloc: don't take two simultaneous locks
Date
Msg-id CA+TgmoZkWfHpjSoA5e=BvTXvL4wtjW0yCWaMYNL2ExReG+7XeA@mail.gmail.com
Whole thread Raw
In response to Re: BufferAlloc: don't take two simultaneous locks  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, Apr 14, 2022 at 11:27 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> If it's not atomic, then you have to worry about what happens if you
> fail partway through, or somebody else changes relevant state while
> you aren't holding the lock.  Maybe all those cases can be dealt with,
> but it will be significantly more fragile and more complicated (and
> therefore slower in isolation) than the current code.  Is the gain in
> potential concurrency worth it?  I didn't think so at the time, and
> the graphs upthread aren't doing much to convince me otherwise.

Those graphs show pretty big improvements. Maybe that's only because
what is being done is not actually safe, but it doesn't look like a
trivial effect.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Intermittent buildfarm failures on wrasse
Next
From: Robert Haas
Date:
Subject: Re: make MaxBackends available in _PG_init