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