Thanks a lot Jacob and Jelte for your valuable insights. I agree that the seamless re-authentication model (re-authentication over the active connection) is suited only for external centralized authentication methods like OAuth2 and LDAP.
I have below questions - Does the client need to pause current operations, execute a simplified re-authentication sequence (triggered by the server's Authentication Request), and then transparently resume the session upon success? - How frequently should the authorization expiration check occur in the backend, Would the frequency be tied to a new session GUC (e.g., authorization_check_interval), allowing administrators to configure it? - What should the behavior be for older version clients (backward compatibility) that do not understand this new server-initiated reauthentication message? In this case is the safest approach for the server to terminate the connection? Thanks & Best Regards, Ajit On Thu, 11 Dec 2025 at 02:50, Jelte Fennema-Nio <[email protected]> wrote: > 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). >
