For the first commits I only have a few more questions/comments about the error messages, otherwise looks good.
> > + libpq_append_conn_error(conn, "failed to lock mutex (%d)", lockerr); > > + return 0; > > + } > > Shouldn't this path return -1, > > We could. I chose zero to try to retain the PG18 behavior, but I could > expand this error message and set request->error instead. If that'd be > less confusing to you as a reader, it's probably worth the change. If this returns 0, we print out failed to lock mutex no OAuth flows are available (try installing the libpq-oauth package) Which isn't ideal, as the library is there, so installing the package wouldn't help. + if ((start_flow = dlsym(state->flow_module, "pg_start_oauthbearer")) == NULL) And this path has the same issue, the library is there, so suggesting to install libpq-oauth isn't helpful. The more detailed message is only printed out with unsafe debugging, without that it just returns 0. + appendPQExpBuffer(&conn->errorMessage, + "use_builtin_flow: failed to lock mutex (%d)\n", + lockerr); This is after an assert, so maybe it is okay as is, but this bypasses gettext. (or shouldn't it use "internal error:" similarly to the other untranslated error message? and another 2 internal errors are translated) > (try installing the libpq-oauth package) This isn't changed in these patches, but Is it okay to assume a package name here? This is not a package that universally exists everywhere, we can't even be sure that pg was installed with a package manager. On RHEL it is called postgresql18-libs-oauth, on suse it's part of the main libpq package. In both cases if for some internal error it can't find/load the library, we suggest installing a package that doesn't exist on that system.
