On Mon, Mar 16, 2026 at 12:45 PM Zsolt Parragi <[email protected]> wrote: > I tried to figure out if this is fine or not, but isn't it the same as > the existing ereport(ERROR, ...) calls everywhere in the sasl/scram > code?
Those are *also* not good, IMHO; they're what I had in mind when I said "it's unusual/invisible". (ERROR is upgraded to FATAL here, so they're also misleading.) OAuth inherited a few of those from SCRAM to avoid divergent behavior for protocol violations, but I don't really want to lock that usage into the SASL architecture by myself, especially not for normal operation. CheckSASLAuth should ideally have control over the logic flow. (It might be nice to make it possible to throw ERRORs from inside authentication code without bypassing the top level. Then maybe we could square that with our treatment of logdetail et al. But we'd have to decide how we want protocol errors to interact with the hook.) On Mon, Mar 16, 2026 at 11:14 AM Jacob Champion <[email protected]> wrote: > I'm working on a three-patch set to add FATAL_CLIENT_ONLY, the new > abandoned state, and the log fix making use of both. Attached as v8. --Jacob
v8-0001-Add-FATAL_CLIENT_ONLY-to-ereport-elog.patch
Description: Binary data
v8-0003-oauth-Don-t-log-discovery-connections-by-default.patch
Description: Binary data
v8-0002-sasl-Allow-backend-mechanisms-to-abandon-exchange.patch
Description: Binary data
