Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51.11.2\))
Subject: Re: [OAuth2] Infrastructure for tracking token expiry time
From: Daniel Gustafsson <daniel@yesql.se>
In-Reply-To: <CAN4CZFPKY2m1bEm51g-1jmBfCMohfe5VFoKuCnbhiGP1FBBNrQ@mail.gmail.com>
Date: Wed, 18 Feb 2026 17:30:24 +0100
Cc: Ajit Awekar <ajitpostgres@gmail.com>,
 VASUKI M <vasukianand0119@gmail.com>,
 PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <7F3C1A8B-F0FF-49BF-A53C-DC043BBB1FE7@yesql.se>
References: <CAER375PhG5an=p1=6QS6vWi=BHxR+ViJmYPDkkEtpgVsfCcu_w@mail.gmail.com>
 <CAE2r8H5QAng_rRrkVmGbLuQSgbMz94tpOOOdJKeuHj=go0nXqg@mail.gmail.com>
 <CAN4CZFOe-0jTR7_s2uciX9TNKxRvd2h8avAw9iFO6VPu0CChsQ@mail.gmail.com>
 <CAER375Oh6U_kqP0SK8OP47vy3PBd4p1C027Gaod3B2bqKgMFoQ@mail.gmail.com>
 <CAN4CZFNV69LS6H87sV-iPO9w_V-_uko4_G_0QKb1cokJvWhF6g@mail.gmail.com>
 <CAE2r8H6Tc6F2BM-JqC+gp-HQKCzfHOx02Xj5MmuS-AY4jfN5iw@mail.gmail.com>
 <CAER375Mtf-7LcR1zNks67k57r3b5yTy9sHxRQ78Y1+xmTVncMw@mail.gmail.com>
 <D3C75650-2FED-41B3-A6BF-E4D8F9E40EAE@yesql.se>
 <CAN4CZFPKY2m1bEm51g-1jmBfCMohfe5VFoKuCnbhiGP1FBBNrQ@mail.gmail.com>
To: Zsolt Parragi <zsolt.parragi@percona.com>
Archived-At: <https://www.postgresql.org/message-id/7F3C1A8B-F0FF-49BF-A53C-DC043BBB1FE7%40yesql.se>
Precedence: bulk

> On 18 Feb 2026, at 13:04, Zsolt Parragi <zsolt.parragi@percona.com> =
wrote:

>> 2. Terminating sessions with expired/revoked tokens before executing =
new
>> commands.
>=20
>> Token expiration is IMHO not a use case for a FATAL error, if we want =
to
>> terminate a connection we can do it in a more graceful way.
>=20
> There are different reasons for token expiration, one is a simple
> timeout where all we have to do is communicate to the client that we
> need a refresh (gracefully), and the other is where a token is
> immediately revoked because of a security incident, in which case
> immediate termination is a good practice.

I understand these cases and agree that there are different needs for =
messaging
to the user for these cases, but I still think that neither should =
overload
what FATAL error means.  The mechanism used is however a secondary =
discussion,
first thing to get in place is a design for how to handle mid-connection
credential expiration.

--
Daniel Gustafsson