On Fri, Jul 7, 2023 at 4:57 AM Jacob Champion <jchamp...@timescale.com> wrote: > On Wed, Jul 5, 2023 at 3:07 PM Thomas Munro <thomas.mu...@gmail.com> wrote: > > 2. Convert those events into new libpq events like 'I want you to > > call me back in 100ms', and 'call me back when socket #42 has data', > > and let clients handle that by managing their own poll set etc. (This > > is something I've speculated about to support more efficient > > postgres_fdw shard query multiplexing; gotta figure out how to get > > multiple connections' events into one WaitEventSet...) > > Something analogous to libcurl's socket and timeout callbacks [1], > then? Or is there an existing libpq API you were thinking about using?
Yeah. Libpq already has an event concept. I did some work on getting long-lived WaitEventSet objects to be used in various places, some of which got committed[1], but not yet the parts related to postgres_fdw (which uses libpq connections to talk to other PostgreSQL servers, and runs into the limitations of PQsocket()). Horiguchi-san had the good idea of extending the event system to cover socket changes, but I haven't actually tried it yet. One day. > > Or, more likely in the > > first version, you just can't do it at all... Doesn't seem that bad > > to me. > > Any initial opinions on whether it's worse or better than a worker thread? My vote is that it's perfectly fine to make a new feature that only works on some OSes. If/when someone wants to work on getting it going on Windows/AIX/Solaris (that's the complete set of no-epoll, no-kqueue OSes we target), they can write the patch. [1] https://www.postgresql.org/message-id/flat/CA%2BhUKGJAC4Oqao%3DqforhNey20J8CiG2R%3DoBPqvfR0vOJrFysGw%40mail.gmail.com
