Content-Type: text/plain; charset=UTF-8; format=Flowed
Date: Tue, 24 Mar 2026 15:29:47 +0100
Message-Id: <DHB31JSR3PTE.3J3PBIXA6JBB2@jeltef.nl>
Cc: "Tomas Vondra" <tomas@vondra.me>, "Zsolt Parragi"
 <zsolt.parragi@percona.com>, "PostgreSQL Hackers"
 <pgsql-hackers@lists.postgresql.org>, "Dave Cramer" <davecramer@gmail.com>,
 "Heikki Linnakangas" <hlinnaka@iki.fi>
Subject: Re: Add GoAway protocol message for graceful but fast server
 shutdown/switchover
To: "Jacob Champion" <jacob.champion@enterprisedb.com>
From: "Jelte Fennema-Nio" <postgres@jeltef.nl>
MIME-Version: 1.0
References: <DDPQ1RV5FE9U.I2WW34NGRD8Z@jeltef.nl>
	<DFJ3E1X9169E.WV892I950LYW@jeltef.nl>
	<DFY0RHAZTTXJ.15AD95RE6A5N5@jeltef.nl>
	<CAN4CZFOw2v9G_9vuP0vnNH8K9X_UeSOyq=gWJp7bdGZ5HKNTDA@mail.gmail.com>
	<DG9X4XC66EMC.2S34SS1SZ8K3K@jeltef.nl>
	<DGBMBCDXXNBG.3CNHEZ9QVB4GL@jeltef.nl>
	<CAN4CZFMLpakQb8qohDAnrOoQ1-UrvmzJewZss95Y+Mf_J+iNeA@mail.gmail.com>
	<DH1JZEYZOBSW.1QEY6MI45FCIL@jeltef.nl>
	<f97528e4-5766-415e-b998-678da925ce05@vondra.me>
	<CAOYmi+mAJ5jF-XrxFz1BAcAPfJCm9Yy1uvRNwfNz8q+1YMKDig@mail.gmail.com>
In-Reply-To: 
 <CAOYmi+mAJ5jF-XrxFz1BAcAPfJCm9Yy1uvRNwfNz8q+1YMKDig@mail.gmail.com>
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/DHB31JSR3PTE.3J3PBIXA6JBB2%40jeltef.nl>
Precedence: bulk

On Fri, 20 Mar 2026 at 21:11, Jacob Champion <jacob.champion@enterprisedb.c=
om> 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