On Wed, 25 Mar 2026 at 01:36, Tatsuo Ishii <[email protected]> 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.
