AW: AW: AW: AW: AW: broken backup trail in case of quickly patroniswitchback and forth

Let me clarify: "But, it might start killing processes after a certain period if a _fast_ shutdown after SIGTERM didn't happen".

I am talking about stopping the Patroni master process with a systemd scipt.

"Zwettler Markus (OIZ)" <Markus.Zwettler@zuerich.ch> wrote on 2019/11/08 07:51:33 AM:

> From: "Zwettler Markus (OIZ)" <Markus.Zwettler@zuerich.ch>
> To: Brad Nicholson <bradn@ca.ibm.com>
> Cc: Adrian Klaver <adrian.klaver@aklaver.com>, "pgsql-
> general@lists.postgresql.org" <pgsql-general@lists.postgresql.org>
> Date: 2019/11/08 07:51 AM
> Subject: [EXTERNAL] AW:  AW: AW: AW: broken backup trail in case of
> quickly patroni switchback and forth
>
> 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.


If it can't do a clean shutdown, that points to something wrong with Postgres itself.  Why doesn't a fast shutdown work for you in those cases?

> It's not a Patroni issue but it's triggered by Patroni as it will do
> "some kind of switchover" on a regular shutdown.

Sure, but you should be looking at why Postgres can't cleanly shutdown.

How are you telling Patroni to switchover? Are you using the Patroni switchover command via patronictl or the API, or sending a signal to the Patroni process?  I think the explicit switchover
command will not behave this way.  It will return you a 503 if it can't switchover and not change the primary (that is something you can confirm with the Patroni developers).

Brad.