> You mean effectively being able to undo sending the GoAway message? Yes.
> 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). I imagine if we would want to change the current PostgreSQL behavior (waiting for shutdown indefinitely when smart shutdown is requested), the new protocol could be a stopper. But, yes, the discussion hasn't started and I admit it is not worth the effort for now. >> 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. Yeah. > 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. Interesting. In Pgpool-II case, client disconnection is not a problem, the connection to PostgreSQL is kept open anyway (if connection expiration is not set). Probably this is because Pgpool-II only supports "session level" connection pooling. > 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. No problem for Pgpool-II. Regards, -- Tatsuo Ishii SRA OSS K.K. English: http://www.sraoss.co.jp/index_en/ Japanese:http://www.sraoss.co.jp
