On Thu, Dec 11, 2025 at 4:36 PM Jelte Fennema-Nio <postgres@jeltef.nl> wrote:
> > "you didn't reauthenticate in time, so now you
> > _have_ to reconnect, bye"
>
> I might be missing something but I feel like we currently do this in
> various other places using:
> FATAL: <message explaining reason>
> <connection close>
Part of the appeal to me is the ability for the client to decide to
transparently reconnect if possible, rather than surfacing an error to
the user. But if there's no other metadata to be used by the client
during that, then I suppose we could create a new 08Pxx SQLSTATE to
mean that. That does cover the backwards compatibility angle pretty
well.
> Yeah, pipelining is annoying for these kind of things. But looking
> it's not so bad. What if you define the flow as:
> 1. server sends 'R' message when it realizes it wants a
> re-authentication (allowed whenever, just like NoticeResponse)
> 2. client can continue to send whatever and server will respond accordingly
> 3a. client starts authentication flow by sending a 'p' message
> 3b. client did not complete auth flow within timeout of the server, so
> server sends FATAL + closes connection.
I think a timeout-based flow (though simple!) might be hard to
maintain for a DBA. It's basically a race condition that they would
have to tune. (I'm not saying I'm opposed to a timeout here; just that
the timeout should be a backstop for a misbehaved client, rather than
the thing the conversation is based on. The client should know what
it's allowed to finish up before reauthenticating.)
--Jacob
