Hi all, On Thu, Jun 26, 2025 at 4:33 PM Jacob Champion <[email protected]> wrote: > My plan, if this code seems reasonable, is to backport 0001-0003, but > keep the larger 0004 on HEAD only until it has proven to be stable. > It's a big new suite and I want to make sure it's not flapping on some > buildfarm animal. Eventually I'll backport that too.
Any thoughts on the approach? Too big/too scary/too BSD-specific? A small bit of self-review: a comment I wrote in the tests suggested that the choice of readable/writable events was up to the multiplexer implementation, but it *must* choose readable, due to the hardcoded use of PGRES_POLLING_READING throughout the current code. Updated in v2. Thanks, --Jacob
1: ddb7875bb58 = 1: 379c12b5d26 oauth: Remove stale events from the kqueue
multiplexer
2: a871ce498ea = 2: f30317d7265 oauth: Remove expired timers from the
multiplexer
3: 5033b6d51c1 = 3: d243d28964d oauth: Track total call count during a client
flow
4: f4a640f7995 ! 4: ca6fd237653 oauth: Add unit tests for multiplexer handling
@@ src/interfaces/libpq-oauth/test-oauth-curl.c (new)
+ *
+ * NB: our current multiplexer implementations (epoll/kqueue) are
*readable*
+ * when the underlying libcurl sockets are *writable*. This behavior is
pinned
-+ * here to record that expectation, but it's not a required part of the
API. If
-+ * you've added a new implementation that doesn't have that behavior,
feel free
-+ * to modify this test.
++ * here to record that expectation; PGRES_POLLING_READING is hardcoded
++ * throughout the flow and would need to be changed if a new multiplexer
does
++ * something different.
+ */
+#define mux_is_ready(MUX, DEADLINE, TEST) \
+ do { \
v2-0001-oauth-Remove-stale-events-from-the-kqueue-multipl.patch
Description: Binary data
v2-0002-oauth-Remove-expired-timers-from-the-multiplexer.patch
Description: Binary data
v2-0003-oauth-Track-total-call-count-during-a-client-flow.patch
Description: Binary data
v2-0004-oauth-Add-unit-tests-for-multiplexer-handling.patch
Description: Binary data
