Re: Resetting recovery target parameters in pg_createsubscriber

From: Alena Vinter <dlaaren8(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Ilyasov Ian <ianilyasov(at)outlook(dot)com>, "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Resetting recovery target parameters in pg_createsubscriber
Date: 2025-10-27 12:22:12
Message-ID: CAGWv16LeHght+1xKWF6T33pcveGXBCQuK+MpaJKezaD_AcXhPw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi everyone,

Michael, thank you for outlining your alternative approach.
After rethinking the current patch state with a clearer vision, I realized
that simply truncating the postgresql.auto.conf file is sufficient. All
modifications made by pg_createsubscriber in this file are append-only, so
truncation reliably restores it to its original state without adding extra
logic. This keeps the patch small and clean.

For older versions using recovery.conf, the situation differs — since that
file is fully rewritten during recovery setup, we instead restore the
previously saved original file using a durable rename.

Regarding debugging: the contents are not entirely lost. pg_createsubscriber
already prints the new recovery configuration as debug output, so the full
parameter set remains visible in the logs for inspection when needed. My
point is that adding include directives isn't needed, as we already have
debug output, and, moreover, they aren't applied to recovery.conf.

Robert, this scenario actually occurred in production at one of our
customer environments. Even though this workflow may be uncommon,
PostgreSQL should still handle it gracefully. The fact that the server can
end up in a state where it cannot start because it fails to reach a
recovery target point far in the past suggests a potential area for
improvement in the recovery process. It would be helpful if the system
could detect such a case — where the recovery target precedes the current
consistent point — and either skip recovery or emit a clear diagnostic
message rather than failing to start.

Best regards,
Vinter Alena

Attachment Content-Type Size
v8-0001-Reseting-recovery-target-parameters-in-pg_createsubs.patch text/x-patch 8.0 KB
v8-0002-doc-Add-warning-about-leftover-recovery-parameters-i.patch text/x-patch 1.9 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2025-10-27 12:42:30 Re: POC: enable logical decoding when wal_level = 'replica' without a server restart
Previous Message Alexander Korotkov 2025-10-27 12:13:36 Re: Add SPLIT PARTITION/MERGE PARTITIONS commands