On Mon, 15 Dec 2025 at 18:17, Jacob Champion
<jacob.champion@enterprisedb.com> wrote:
> 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.
Seems reasonable to use dedicated error code for that. My
understanding (see below) would be that getting this error would be
the exception, because in the happy path the client would
re-authenticate on the existing connection.
> > 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.)
To clarify: I meant the timeout as a backstop in this flow. Once the
client receives a 'R' message it should be re-authenticating ASAP. But
if it still had some messages in flight, the server can still choose
to process them during a grace period.
