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

From Jelte Fennema-Nio
Subject Re: Periodic authorization expiration checks using GoAway message
Date
Msg-id CAGECzQS5e+UV+RRBuh1pWOe6BUXj-87xJd_zztd2neZj_b4DkQ@mail.gmail.com
Whole thread Raw
In response to Re: Periodic authorization expiration checks using GoAway message  (Jacob Champion <jacob.champion@enterprisedb.com>)
List pgsql-hackers
On Mon, 15 Dec 2025 at 18:31, Jacob Champion
<jacob.champion@enterprisedb.com> wrote:
> But it seems iffy to change authentication metadata associated with
> the connection halfway through a transaction, no? Am I missing
> something that makes that architecturally safe?

It felt a bit iffy to me too initially, but then I started looking at
it from the other direction: i.e. what am I missing that actually
makes this architecturally unsafe? And I cannot think of anything.

I see two possible things happening when re-authenticating mid-transaction:
1. User re-authenticates correctly, the transaction can continue as it
would normally
2. User re-authenticates incorrectly, connection is closed and
transaction is aborted

Both of those situations seem totally reasonable to me. What metadata
are you worried about changing mid transaction that could mess stuff
up? The primary one I can imagine is the username, but in my proposed
implementation of the feature that one would have to stay the same
anyway: The authentication related messages ('R' and 'p') don't
contain username, that's part of the StartupMessage.



pgsql-hackers by date:

Previous
From: Melanie Plageman
Date:
Subject: Re: Checkpointer write combining
Next
From: Melanie Plageman
Date:
Subject: Re: Checkpointer write combining