Re: Periodic authorization expiration checks using GoAway message

Zsolt Parragi <zsolt.parragi@percona.com>

From: Zsolt Parragi <zsolt.parragi@percona.com>
To: Ajit Awekar <ajitpostgres@gmail.com>
Cc: Jacob Champion <jacob.champion@enterprisedb.com>, Jelte Fennema-Nio <postgres@jeltef.nl>, Hannu Krosing <hannuk@google.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>, Dave Cramer <davecramer@gmail.com>, Heikki Linnakangas <hlinnaka@iki.fi>
Date: 2025-12-17T10:44:25Z
Lists: pgsql-hackers
> To me that seems like a matter of policy and not protocol. (As long as
> we come to some agreement on the semantics of what a client is and is
> not allowed to do before reauthenticating.)

It's great if this is configurable, as long as DBAs can choose both
the immediate and graceful options.

> Is the hope that batching validation will make things more efficient,
> or is there another goal to using a background process? You still have
> to communicate back to each backend.

* I think I can implement it with background threads / immediate
disconnection currently for PG18 in our validator (this of course
might improve with PG19 and later)
* Can we implement the immediate disconnection without a background
process? I would again use the long running query example. If a query
is running for 5-10-... minutes, is there another way to disconnect
the connection before the query completes?
* 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).