Re: Windows sockets (select missing events?)

Hi Ranier,

I doubt it really matters, unless perhaps it's upsetting some static
analysis tool? It's bounded by FD_SETSIZE, a small number.

FWIW, I would like to delete pgwin32_select() in PG17. Before PG16
(commit 7389aad6), the postmaster used it to receive incoming
connections, but that was replaced with latch.c code. I think the
main other place that uses select() in the backend is in the RADIUS
authentication code. That's arguably a bug, and should be replaced
with WaitEventSet too. I wrote a patch like that, but haven't got
back to it yet:

https://www.postgresql.org/message-id/flat/CA%2BhUKGKxNoVjkMCksnj6z3BwiS3y2v6LN6z7_CisLK%2Brv%2B0V4g%40mail.gmail.com

If we could get that done, hopefully pgwin32_select() could go? Are
there any more callers hiding somewhere?

I'd also like to remove various other socket API wrapper functions in
that file. They exist to support blocking mode (our Windows sockets
are always in non-blocking mode at the OS level, but we simulate
non-blocking with our own user space wait loops in those wrappers),
and we also have some kludges to support connectionless datagrams
(formerly used for talking to the defunct stats backend, no longer
needed AFAICS). But when I started looking into all that, I realised
that I'd first need to work on removing a few more straggler places
that use blocking mode for short stretches in the backend. That is,
make it 100% true that sockets in the backend are always in
non-blocking mode. I think that seems like a good goal, because any
place still using blocking mode is a place where a backend might hang
uninterruptibly (on any OS).

A closely related problem is fixing the socket event-loss problems we
have on Windows https://commitfest.postgresql.org/46/3523/, which is
moving at a glacial pace because I am not a Windows guy. Eventually I
want to use long-lived WaitEventSet in lots of places for better
efficiency on all systems, and that seems to require fixing that
historical bug in our per-socket event tracking. I think the end
point of all that is: we'd lose the wrappers that deal with
fake-blocking-mode and fake-signals, and lose the right to use
blocking signals at all in the backend, but keep just a few short
win32 wrappers that help track events reliably.