Re: Add client connection check during the execution of the query

On Sat, Dec 11, 2021 at 7:09 PM Thomas Munro <thomas.munro@gmail.com> wrote:
> On Sat, Dec 11, 2021 at 6:11 PM Andres Freund <andres@anarazel.de> wrote:
> > Yuck. Is there really no better way to deal with this? What kind of errors is
> > this trying to handle transparently? Afaics this still changes when we'd
> > e.g. detect postmaster death.
>
> The problem is that WaitEventSetWait() only reports the latch, if it's
> set, so I removed it from the set (setting it to NULL), and then undo
> that afterwards.  Perhaps we could fix that root problem instead.
> That is, we could make it so that latches aren't higher priority in
> that way, ie don't hide other events[1].  Then I wouldn't have to
> modify the WES here, I could just ignore it in the output event list
> (and make sure that's big enough for all possible events, as I had it
> in the last version).  I'll think about that.

I tried that.  It seems OK, and gets rid of the PG_FINALLY(), which is
nice.  Latches still have higher priority, and still have the fast
return if already set and you asked for only one event, but now if you
ask for nevents > 1 we'll make the syscall too so we'll see the
WL_SOCKET_CLOSED.

It's possible that someone might want the old behaviour one day (fast
return even for nevents > 1, hiding other events), and then we'd have
to come up with some way to request that, which is the type of tricky
policy question that had put me off "fixing" this before.  But I guess
we could cross that bridge if we come to it.  Everywhere else calls
with nevents == 1, so that's hypothetical.

Better?