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.
