On Thu, Dec 11, 2025 at 2:52 AM Ajit Awekar <ajitpostgres@gmail.com> wrote:
> I agree that the seamless re-authentication model (re-authentication over the active connection) is suited only for
externalcentralized authentication methods like OAuth2 and LDAP.
Well, see my response to Jelte above. But I think it's certainly
easier to pitch the usefulness of the feature for external methods.
> Does the client need to pause current operations, execute a simplified re-authentication sequence (triggered by the
server'sAuthentication Request), and then transparently resume the session upon success?
I think it would have to. But we don't number our conversations like
the other protocols with GOAWAY do, so it's not immediately clear to
me how we would do it.
The reauthentication sequence isn't guaranteed to be silent, either.
Imagine that you were typing a SQL command and psql popped up a
password prompt right in the middle; that's not a good user
experience.
> How frequently should the authorization expiration check occur in the backend, Would the frequency be tied to a new
sessionGUC (e.g., authorization_check_interval), allowing administrators to configure it?
I don't think there's one answer, so it'd probably have to be
configurable. Offline tokens and Kerberos tickets might have a known
timestamp for expiration, so you could just do a cheap timestamp
comparison for every single request. Online checks (to allow
revocation) would need more thought by the DBA; there's a
performance-staleness tradeoff there.
> What should the behavior be for older version clients (backward compatibility) that do not understand this new
server-initiatedreauthentication message? In this case is the safest approach for the server to terminate the
connection?
"Safe" is decided by the DBA, I think. Turning this on might imply
that you care more about security than the cost of cleaning up after a
client that got kicked off halfway through an important transaction...
or it might not.
--Jacob
