Re: Add client connection check during the execution of the query - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: Add client connection check during the execution of the query
Date
Msg-id CA+hUKGK1VxwNVa5PuP=EOZY=SXQ=757efiQLd_-_FgiAiagc4A@mail.gmail.com
Whole thread Raw
In response to Re: Add client connection check during the execution of the query  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: Add client connection check during the execution of the query
List pgsql-hackers
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.

Attachment

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: row filtering for logical replication
Next
From: Ronan Dunklau
Date:
Subject: Re: Proposal: More structured logging