| From: | "Jelte Fennema-Nio" <postgres(at)jeltef(dot)nl> |
|---|---|
| To: | "Jacob Champion" <jacob(dot)champion(at)enterprisedb(dot)com> |
| Cc: | "Tomas Vondra" <tomas(at)vondra(dot)me>, "Zsolt Parragi" <zsolt(dot)parragi(at)percona(dot)com>, "PostgreSQL Hackers" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "Dave Cramer" <davecramer(at)gmail(dot)com>, "Heikki Linnakangas" <hlinnaka(at)iki(dot)fi> |
| Subject: | Re: Add GoAway protocol message for graceful but fast server shutdown/switchover |
| Date: | 2026-03-24 14:29:47 |
| Message-ID: | DHB31JSR3PTE.3J3PBIXA6JBB2@jeltef.nl |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, 20 Mar 2026 at 21:11, Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> wrote:
> I'd been wondering about these as well, but in the context of the
> tangential thread [1]. HTTP has much stronger semantics for its GOAWAY
> frames, for instance.
I reread the HTTP/3 GOAWAY spec[1], but I think our protocol is too
different from HTTP/3 to take any lessons from it (at the moment at
least). HTTP/3 "streams" are independent, we have no such concept. Our
whole session is a single stream, due to all of our session state. So
the semantics that on a single connection a client cannot open newer
streams does not really mean any useful for us, i.e. there's no way to
open a new stream. Even the "which messages have definitely not been
processed feature" can already be inferred from the server right now, by
tracking what responses have been received before the server closes the
connection. So I cannot think of any useful payload to add to the GoAway
message.
[1]: https://www.rfc-editor.org/rfc/rfc9114.html#connection-shutdown
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jelte Fennema-Nio | 2026-03-24 14:32:36 | Re: Change default of jit to off |
| Previous Message | Lukas Fittl | 2026-03-24 14:28:42 | Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc? |