Hi, On 2021-12-13 17:51:00 +1300, Thomas Munro wrote: > On Sat, Dec 11, 2021 at 7:09 PM Thomas Munro <thomas.mu...@gmail.com> wrote: > > On Sat, Dec 11, 2021 at 6:11 PM Andres Freund <and...@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
