Re: Periodic authorization expiration checks using GoAway message

On Wed, Dec 10, 2025 at 1:21 PM Jelte Fennema-Nio <postgres(at)jeltef(dot)nl> wrote:
> I think password rollover without downtime requires more thought than
> discussed in this thread so far.

Sure. See also

https://postgr.es/m/CAGB%2BVh5SQQorNDEKP%2B0G%3DsmxHRhbhs%2BVkmQWD5Vh98fmn8X4dg%40mail.gmail.com

> Reading between the lines, I guess you're looking at this from the
> OAuth lens.

Yes. Or Kerberos.

> Not "normal" passwords.

I could see a case for kicking connections after a SCRAM password
change, if they're not able to reauthenticate in X interval. But I
wouldn't make it my top priority, necessarily.

> > 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.

Just that the two cases of "please consider reconnecting due to a
topology change" and "you didn't reauthenticate in time, so now you
_have_ to reconnect, bye" seem like they might be related at the
protocol level, since some types of topology changes might warrant a
harsher approach, and some types of authentication might do well with
a gentler one.

> 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.

Agreed; I did not mean that.

> 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).

I think that's probably the hard part. "in between" is not
particularly well-defined, especially once you add in some async
pipelining, right? Contrast with HTTP/3's GOAWAY, especially its
graceful shutdown flow.

--Jacob