Thread

Re: Resetting recovery target parameters in pg_createsubscriber

Alena Vinter <dlaaren8@gmail.com> — 2025-10-27T12:22:12Z

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