Re: Periodic authorization expiration checks using GoAway message

Hello Hackers,

I am submitting a patch to implement password expiration enforcement for
active backend sessions. Currently, Postgres checks rolvaliduntil during
the initial connection, but changes to a user's expiration time do not
affect currently for established sessions.

This patch addresses that by utilizing the SysCache invalidation mechanism
to trigger re-validation of credentials during a backend's lifetime.

Please find below summary of changes

During the authentication phase in function get_role_password, the user's
rolvaliduntil timestamp is cached into a new global variable,
password_valid_until_timestamp.
A callback, AuthCacheInvalidated, is registered for the AUTHOID cache.
Whenever pg_authid is modified, this sets a local AuthCheckNeeded flag.
In exec_simple_query, if AuthCheckNeeded is true, the backend performs a
fresh SysCache lookup to refresh the cached expiration timestamp.
password_valid_until_timestamp is added to globals.c to track expiration
state across the backend.
This approach avoids the overhead of polling pg_authid on every query while
ensuring that security policy changes take effect immediately for active
connections.

I have attached a patch (password_expiration_enforcement.diff) and request
a review.

Thanks & Best regards,
Ajit

On Tue, 6 Jan 2026 at 22:16, Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>
wrote:

> On Wed, Dec 17, 2025 at 2:44 AM Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>
> wrote:
> > * Some identity providers support pushing revocation data instead of
> > pulling, and this usually works over HTTP. Which means that it needs a
> > background process running a mini HTTP server (as part of an oauth
> > validator).
>
> (It's not really any of my business, but I feel compelled to say, as
> someone who used to play the embedded web server game: HTTP server
> implementations should be process-isolated away from Postgres shared
> memory.)
>
> --Jacob
>