> 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).
