On Tue, Dec 14, 2021 at 11:50 PM Thomas Munro <thomas.munro@gmail.com> wrote:
> On Tue, Dec 14, 2021 at 11:18 AM Thomas Munro <thomas.munro@gmail.com> wrote:
> > Well, I was trying to avoid bikeshedding an API change just for a
> > hypothetical problem we could solve when the time comes (say, after
> > fixing the more egregious problems with Append's WES usage), but here
> > goes: we could do something like AddWaitEventToSet(FeBeWaitSet,
> > WL_LATCH_SET_LOPRIO, ...) that is translated to WL_LATCH_SET
> > internally but also sets a flag to enable this
> > no-really-please-poll-all-the-things-if-there-is-space behaviour.
That API is probably useless for anything else and is just too
complicated for what it's doing here.
I considered another idea we discussed: if we see a latch event, clear
it and try again so that other events can be revealed (rince and
repeat), but remember if that happens and set the latch at the end. I
think that still requires PG_FINALLY() if you want to guarantee not to
eat a latch event if WaitEventSetWait() throws. This may be a
theoretical point because things must be pretty broken if
WaitEventSetWait() is throwing, but I don't like an egregious lack of
exception safety on principle.
So I think I had it better in the beginning: just mute the latch, and
then unmute it at the end in a PG_FINALLY() block. I'm back to
proposing that short and sweet version, this time with some minor
cleanup.