[draft] demote primary to standby

From: Jehan-Guillaume de Rorthais <jgdr(at)dalibo(dot)com>
To: "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: [draft] demote primary to standby
Date: 2025-06-12 17:14:45
Message-ID: 20250612191445.7226c2d0@karst
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi all,

I went back to my old patch about the "demote" action[1].

# Why?

The goal of the "demote" action is the opposite of the "promote" one: it
turns an "in production" instance to a standby one. This is a required step
to make cluster management easier, as instance, for switching over the
primary role from a node to another one. This is a common cluster scenario
during eg. software maintenance/upgrade.

This can also be useful for clusterware where instances state can be changed
from one way or the other. At least Patroni, pg_auto_failover and Pacemaker
agents have some demote related code that actually shutdown the instance and
sometime start it back as a standby.

# State of the patch

This patch is a draft. I removed a lot of code and complexity compared to my
previous version. It only focus on demoting a node using a "demote
checkpoint" after stopping all existing user backends.

This is a first incremental step just to settle various complexities before
moving ahead.

The tests focus on 2PC, some limited writes and checking if everything is
following/surviving gracefully during demote/promote/switchover.

# TODO

* cleaner code to handle various subsystem

Current draft vaguely deal with various subsystems from ShutdownXLOG() and
StartupXLOG(). The code in StartupXLOG() was kind of a test/fail/retry
session so things /seems/ to work.

A serious study and better code flow is needed to re-init the subsystem
correctly, with better explanations and comments.

I try to deal with MultiXact and Prepared Transactions in this patch, let me
know what you think this code design.

* remove the checkpoint

Robert Haas pointed in previous discussion that the checkpoint was an issue
as the demote action needed to be fast to be useful. Waiting for minutes for
the checkpoint to finish in various scenario is not acceptable, as expressed
here:
https://www.postgresql.org/message-id/flat/CA%2BTgmoYe8uCgtYFGfnv3vWpZTygsdkSu2F4MNiqhkar_UKbWfQ%40mail.gmail.com#2a488f8c2ea1696197d9edf98fcb4472

I still have to think about how the demote can be executed without the this
checkpoint. Any advice, warning, idea about this topic is appreciated.

Thank you!

[1] https://www.postgresql.org/message-id/flat/20200617174451.222078b4%40firost

Attachment Content-Type Size
v1-0001-Demote-draft-using-dedicated-checkpoint.patch text/x-patch 51.1 KB
v1-0002-Add-demote-tests.patch text/x-patch 6.9 KB

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2025-06-12 17:23:11 Re: pg_dump --with-* options
Previous Message Masahiko Sawada 2025-06-12 17:00:12 Re: Make COPY format extendable: Extract COPY TO format implementations