It depends. It is a switchover if Patroni could to a clean shutdown. But, it might start killing processes after a certain period if a normal shutdown after SIGTERM didn't happen. This would not be a switchover anymore. In other words there is no guarantee for a "clean" switchover. This might be the reason why the Patroni guys are always talking about failover only.
It's not a Patroni issue but it's triggered by Patroni as it will do "some kind of switchover" on a regular shutdown. "Zwettler Markus (OIZ)" <markus.zwett...@zuerich.ch<mailto:markus.zwett...@zuerich.ch>> wrote on 2019/11/07 11:32:42 AM: > From: "Zwettler Markus (OIZ)" > <markus.zwett...@zuerich.ch<mailto:markus.zwett...@zuerich.ch>> > To: Adrian Klaver > <adrian.kla...@aklaver.com<mailto:adrian.kla...@aklaver.com>>, "pgsql- > gene...@lists.postgresql.org<mailto:gene...@lists.postgresql.org>" > <pgsql-general@lists.postgresql.org<mailto:pgsql-general@lists.postgresql.org>> > Date: 2019/11/07 11:33 AM > Subject: [EXTERNAL] AW: AW: AW: broken backup trail in case of > quickly patroni switchback and forth > > 3) > Patroni does only failovers. Also in case of regular shutdown of the > primary. A failover is a promote of the standby + automatic > reinstate (pg_rewind or pg_basebackup) of the former primary. This is not accurate. Patroni does controlled switchovers as well as failovers. Controlled switchover issues a fast shutdown to Postgres, hard ones issue an immediate shutdown. From this point, it's how Postgres responds to those that matter. Fast shutdown will attempt to ensure the wal stream is transmitted to the replica and the wal files are archived. Immediate shutdown will not do any of this. This issue explains more about when Patroni may choose an immediate shutdown (it might not be totally accurate anymore as it's a year old). https://github.com/zalando/patroni/issues/837#issuecomment-433686687 I agree with the Patroni folks that this is not a Patroni issue, but simply how Postgres responds to the required shutdown types.
