On Wed, 10 Dec 2025 at 21:02, Jacob Champion <[email protected]> wrote: > > (To call it out explicitly: I work with Ajit, and I asked him to take > a look at GoAway, and I'm particularly interested in the > "reauthenticate or else" case. Let me know if any of that is > problematic -- or if anyone's worried that it will become so -- so I > can course-correct sooner rather than later.)
I think password rollover without downtime requires more thought than discussed in this thread so far. Currently the simplest way (that I know of) to rollover passwords without downtime is to have two users that you can switch between, and one has been configured with: ALTER USER b SET ROLE = a; So both effectively log in as a. Reading between the lines, I guess you're looking at this from the OAuth lens. Not "normal" passwords. > On Fri, Nov 28, 2025 at 9:52 AM Hannu Krosing <[email protected]> wrote: > > Also have not looked at the patch, but we should also make sure that > > there is not just be GoAway, but also a way to re-authenticate or > > "extend lease" or whatever the terminology is for a specific > > authentication method. > > I agree. I like the idea of the server coordinating (and then > enforcing) connection lifetime and cross-connection handoffs with the > client, but like Jelte said, the current GoAway proposal isn't really > built for that. If you want to re-authenticate over the existing connection (and keeping your session etc), then I think that's a very different thing than what I intended the GoAway message to be used for. > Is there enough interest in the more general problem for us to try > combining the use cases? Or should they remain separate? I'm not sure what you mean with "combine the use cases". If you think the GoAway protocol message definition could be extended slightly to better serve this use case somehow. For instance if you think we should have the GoAway message include an (optional) number of seconds, so a client could say to the user: "Disconnect within 6 minutes". (just an example, not necessarily something I think is a good idea) If you mean combining by introducing a single shared protocol message for both the "re-authenticate on existing session" and "please reconnect asap", then I'd say: No, let's keep them separate. I think for "re-authenticate now on existing connection" it'd be much more natural for the server to simply send a new authentication request message, and expect the client to respond to that. The auth flow based on these messages is already implemented by each client, they'd only need to change it so that it could be called into at any moment (or maybe certain defined moments like in between queries).
