Re: Periodic authorization expiration checks using GoAway message
Jelte Fennema-Nio <postgres@jeltef.nl>
From: Jelte Fennema-Nio <postgres@jeltef.nl>
To: Jacob Champion <jacob.champion@enterprisedb.com>
Cc: Hannu Krosing <hannuk@google.com>, Ajit Awekar <ajitpostgres@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>,
Dave Cramer <davecramer@gmail.com>, Heikki Linnakangas <hlinnaka@iki.fi>
Date: 2025-12-12T00:36:08Z
Lists: pgsql-hackers
On Fri, 12 Dec 2025 at 01:10, Jacob Champion <jacob.champion@enterprisedb.com> wrote: > https://postgr.es/m/CAGB%2BVh5SQQorNDEKP%2B0G%3DsmxHRhbhs%2BVkmQWD5Vh98fmn8X4dg%40mail.gmail.com Thanks, I hadn't seen that one before. > "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> > I think that's probably the hard part. "in between" is not > particularly well-defined, especially once you add in some async > pipelining, right? 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.