Re: Periodic authorization expiration checks using GoAway message
| От | Jelte Fennema-Nio |
|---|---|
| Тема | Re: Periodic authorization expiration checks using GoAway message |
| Дата | |
| Msg-id | CAGECzQR2P8aO9tDnavLupaTAvD3Fv5e=rq0nfJ=NzT=_U2Wn5g@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Periodic authorization expiration checks using GoAway message (Jacob Champion <jacob.champion@enterprisedb.com>) |
| Ответы |
Re: Periodic authorization expiration checks using GoAway message
|
| Список | 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.
В списке pgsql-hackers по дате отправления: