Re: Add GoAway protocol message for graceful but fast server shutdown/switchover

On Wed, 25 Mar 2026 at 01:36, Tatsuo Ishii <ishii(at)postgresql(dot)org> wrote:
> 1. If clients do not disconnect a session even if they have received
> the GoAway message, PostgreSQL server will give up the shutdown
> sequence. In this case, shouldn't the PostgreSQL server send a
> message indicating "I have given up the smart shutdown request"?
> Otherwise, the fact that GoAway has been received will remain in
> the client, and if the client does not check the receiving timely,
> the client may exit the session unnecessarily.

You mean effectively being able to undo sending the GoAway message?

As the patch is right now, the server will never give up on the
shutdown sequence. It will wait indefinitely until it can shut down.
This is unchanged from the current smart shutdown mode behaviour on
master.

I think it's an interesting idea, but I don't think it's worth the
cost of implementing and maintaining. I don't think it's common for
programs to support cancelling a shutdown sequence. I can't think of
any databases or network services I worked with that support it.
Generally if you want something to shut down, there's a slow graceful
way, and a fast non-graceful way. I personally when the slow graceful
shutdown did not finish "in time for me", I have never felt the need
to cancel the shutdown sequence. Instead I normally trigger the fast
non-graceful shutdown at that point (either manually or through some
automated timeout).

> 2. Can we use a NOTICE message instead of the new protocol GoAway for
> the purpose?

It's a good question. Sadly not easily, e.g. `client_min_messages`
WARNING or ERROR will make sure that won't get sent to the client.

I also thought about adding a read-only parameter and use
ParameterStatus instead of a new message, i.e. similar to how a server
reports its hot_standby status.

A significant issue also arises when the connection isn't made
directly to Postgres, but instead involving poolers like PgBouncer.
The GoAway signal is conceptually a link-level message, i.e. it's
about the connection directly to Postgres that should be disconnected.
But generally proxies forward all messages from Postgres to the
client. But if it does that, the client will disconnect, while the
pooler keeps the connection open to the server. So now the client
disconnected from PgBouncer for no reason, but the connection to
Postgres is still there. I don't think that's behaviour we want to
happen.

That's why I think it would actually be good to have the GoAway
message be opt-in at the connection level, so if an old PgBouncer
doesn't know how to deal with it, it won't forward it accidentally to
the client.