Re: Periodic authorization expiration checks using GoAway message
Jacob Champion <jacob.champion@enterprisedb.com>
From: Jacob Champion <jacob.champion@enterprisedb.com>
To: Zsolt Parragi <zsolt.parragi@percona.com>
Cc: Jelte Fennema-Nio <postgres@jeltef.nl>, Hannu Krosing <hannuk@google.com>, Ajit Awekar <ajitpostgres@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>,
Dave Cramer <davecramer@gmail.com>, Heikki Linnakangas <hlinnaka@iki.fi>
Date: 2025-12-16T20:19:51Z
Lists: pgsql-hackers
On Tue, Dec 16, 2025 at 12:05 AM Zsolt Parragi <zsolt.parragi@percona.com> 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