On Tue, Dec 16, 2025 at 12:05 AM Zsolt Parragi <[email protected]> wrote: > a. The user presses the "logout everywhere" button > b. The users permissions change > c. The user is deactivated (e.g. employee termination) > d. A security check invalidates the user's session > > From these four, I think graceful logout/continuing the current query > is only an option for (a), maybe (b), for (c) and (d) we should log > out the user from everywhere as soon as possible.
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.) Said another way: it seems very useful to let a DBA choose between graceful reauthentication and hard connection loss for different situations. But I don't think those decisions should be assumed in the protocol design or hardcoded in our server. Even for case (d), a DBA might choose to bound clients via transaction_timeout for a particular application; since we've never had this feature before, I don't want to make proclamations about how people are going to want to deploy it. --Jacob
