Hi,
On 2021-12-13 17:51:00 +1300, Thomas Munro wrote:
> 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.
Isn't a certain postgres committer that cares a lot about unnecessary syscalls
going to be upset about this one? Even with the nevents > 1 optimization? Yes,
right now there's no other paths that do so, but I don't like the corner this
paints us in.
From a different angle: Why do we need to perform the client connection check
if the latch is set?
Greetings,
Andres Freund