On Thu, Dec 11, 2025 at 2:52 AM Ajit Awekar <[email protected]> wrote: > I agree that the seamless re-authentication model (re-authentication over the > active connection) is suited only for external centralized 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's Authentication > 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 session GUC (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-initiated > reauthentication 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
