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+TgmobXcqsPhej_opBkCYO7aSh-TheesBVRF2P1k15OCkzkzQ@mail.gmail.com
Whole thread Raw
In response to Re: BufferAlloc: don't take two simultaneous locks  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Responses Re: BufferAlloc: don't take two simultaneous locks  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Re: BufferAlloc: don't take two simultaneous locks  (Yura Sokolov <y.sokolov@postgrespro.ru>)
List pgsql-hackers
On Fri, Apr 15, 2022 at 4:29 AM Kyotaro Horiguchi
<horikyota.ntt@gmail.com> wrote:
> The patch removes buftable entry frist then either inserted again or
> returned to freelist.  I don't understand how it can be in both
> buftable and freelist..  What kind of trouble do you have in mind for
> example?

I'm not sure. I'm just thinking about potential dangers. I was more
worried about it ending up in neither place.

> So, does this get progressed if someone (maybe Yura?) runs a
> benchmarking with this method?

I think we're talking about theoretical concerns about safety here,
and you can't resolve that by benchmarking. Tom or others may have a
different view, but IMHO the issue with this patch isn't that there
are no performance benefits, but that the patch needs to be fully
safe. He and I may disagree on how likely it is that it can be made
safe, but it can be a million times faster and if it's not safe it's
still dead.

Something clearly needs to be done to plug the specific problem that I
mentioned earlier, somehow making it so we never need to grow the hash
table at runtime. If anyone can think of other such hazards those also
need to be fixed.

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



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Re: fix cost subqueryscan wrong parallel cost
Next
From: Robert Haas
Date:
Subject: Re: Add --{no-,}bypassrls flags to createuser