MIME-Version: 1.0
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>
 <7F3C1A8B-F0FF-49BF-A53C-DC043BBB1FE7@yesql.se>
In-Reply-To: <7F3C1A8B-F0FF-49BF-A53C-DC043BBB1FE7@yesql.se>
From: Zsolt Parragi <zsolt.parragi@percona.com>
Date: Wed, 18 Feb 2026 16:58:58 +0000
Message-ID: <CAN4CZFMaAvHSBbQ25o=yiWqn=p7jBNUBABZvqoU1x1-7NWPH9Q@mail.gmail.com>
Subject: Re: [OAuth2] Infrastructure for tracking token expiry time
To: Daniel Gustafsson <daniel@yesql.se>
Cc: Ajit Awekar <ajitpostgres@gmail.com>, VASUKI M <vasukianand0119@gmail.com>, 
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://www.postgresql.org/message-id/CAN4CZFMaAvHSBbQ25o%3DyiWqn%3Dp7jBNUBABZvqoU1x1-7NWPH9Q%40mail.gmail.com>
Precedence: bulk

> but I still think that neither should overload
> what FATAL error means

I see, I misunderstood what you meant by graceful there. In this case,
this is also a good comment for the password expiration thread,
currently that also uses FATAL errors for terminating a connection
when the password expires.

What other option do you see? Something new for this use case like
GoAway, and clients not understanding it simply get disconnected after
some grace period? Or using the recently merged connectionWarning to
send a warning to the client, and disconnect it shortly if it doesn't
do anything to fix the situation?

When I tested the password expiration patch I noticed that deleted
users who still have remaining active connections currently get ERRORs
for every statement that requires permission checks, so in this regard
using ERROR/FATAL for the situation seemed fine to me - it's similar
to what already happens in some edge cases with authentication.