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

From Simon Riggs
Subject Re: BufferAlloc: don't take two simultaneous locks
Date
Msg-id CANbhV-H-Nd9B_dhvUSTKfHvLNNjCe58U-=ENCMqHnuxe9sbiKg@mail.gmail.com
Whole thread Raw
In response to Re: BufferAlloc: don't take two simultaneous locks  (Yura Sokolov <y.sokolov@postgrespro.ru>)
Responses Re: BufferAlloc: don't take two simultaneous locks  (Yura Sokolov <y.sokolov@postgrespro.ru>)
List pgsql-hackers
On Fri, 25 Feb 2022 at 09:24, Yura Sokolov <y.sokolov@postgrespro.ru> wrote:

> > This approach is cleaner than v1, but should also perform better
> > because there will be a 1:1 relationship between a buffer and its
> > dynahash entry, most of the time.
>
> Thank you for suggestion. Yes, it is much clearer than my initial proposal.
>
> Should I incorporate it to v4 patch? Perhaps, it could be a separate
> commit in new version.

I don't insist that you do that, but since the API changes are a few
hours work ISTM better to include in one patch for combined perf
testing. It would be better to put all changes in this area into PG15
than to split it across multiple releases.

> Why there is need for this? Which way backend could be forced to abort
> between BufTableReuse and BufTableAssign in this code path? I don't
> see any CHECK_FOR_INTERRUPTS on the way, but may be I'm missing
> something.

Sounds reasonable.

-- 
Simon Riggs                http://www.EnterpriseDB.com/



pgsql-hackers by date:

Previous
From: "Gunnar \"Nick\" Bluth"
Date:
Subject: Re: PATCH: add "--config-file=" option to pg_rewind
Next
From: Yura Sokolov
Date:
Subject: Re: BufferAlloc: don't take two simultaneous locks