Horton

Re: Improve OAuth discovery logging

Zsolt Parragi <zsolt.parragi@percona.com>

View thread View on postgr.es
From: Zsolt Parragi <zsolt.parragi@percona.com>
To: Jacob Champion <jacob.champion@enterprisedb.com>
Cc: Andrey Borodin <x4mmm@yandex-team.ru>, Chao Li <li.evan.chao@gmail.com>, Daniel Gustafsson <daniel@yesql.se>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>, Michael Paquier <michael@paquier.xyz>, Tom Lane <tgl@sss.pgh.pa.us>
Date: 2026-03-16T19:45:07Z
Lists: pgsql-hackers 
> I don't
> want to escape the authentication flow from inside a SASL mech, though
> (it's unusual/invisible to other maintainers, plus it bypasses the
> ClientAuthentication_hook).

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? I didn't see any clear pattern, for example the LDAP code
clearly uses

ereport(LOG, ...);
return STATUS_ERROR;

 even for internal/configuration errors, while the scram/sasl code
uses ereport(ERROR, ...) for those errors.

Commits

  1. oauth: Don't log discovery connections by default

  2. sasl: Allow backend mechanisms to "abandon" exchanges

  3. Add FATAL_CLIENT_ONLY to ereport/elog

  4. oauth_validator: Avoid races in log_check()