Hi,
Currently all backends have LatchWaitSet (latch.c), and most also have
FeBeWaitSet (pqcomm.c). It's not the end of the world, but it's a
little bit wasteful in terms of kernel resources to have two
epoll/kqueue descriptors per backend.
I wonder if we should consider merging them into a single
BackendWaitSet. The reason they exist is because callers of
WaitLatch() might be woken by the kernel just because data appears on
the FeBe socket. One idea is that we could assume that socket
readiness events should be rare enough at WaitLatch() sites that it's
enough to disable them lazily if they are reported. The FeBe code
already adjusts as required. For example, if you're waiting for a
heavyweight lock or condition variable while executing a query, and
pipelined query or COPY data arrives, you'll spuriously wake up, but
only once and not again until you eventually reach FeBe read and all
queued socket data is drained and more data arrives.
Sketch patch attached. Just an idea, not putting into commitfest yet.
(Besides the wasted kernel sources, I also speculate that things get
pretty confusing if you try to switch to completion based APIs for
more efficient socket IO on various OSes, depending on how you
implement latches. I have some handwavy theories about various
schemes to achieve that on Linux, Windows and FreeBSD with various
different problems relating to the existence of two kernel objects.
Which is a bit more fuel for my early suspicion that postgres_fdw,
which currently creates and destroys WES, should eventually also use
BackendWaitSet, which should be dynamically resizing. But that's for
another time.)
