Re: Periodic authorization expiration checks using GoAway message - Mailing list pgsql-hackers

On Wed, 10 Dec 2025 at 21:02, Jacob Champion
<jacob.champion@enterprisedb.com> 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 <hannuk@google.com> 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).