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

> 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