Re: Periodic authorization expiration checks using GoAway message

On Thu, Dec 11, 2025 at 2:52 AM Ajit Awekar <ajitpostgres(at)gmail(dot)com> 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