Re: Resetting recovery target parameters in pg_createsubscriber - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Resetting recovery target parameters in pg_createsubscriber
Date
Msg-id aS_Gi_7pACVcg0sX@paquier.xyz
Whole thread Raw
In response to Re: Resetting recovery target parameters in pg_createsubscriber  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Resetting recovery target parameters in pg_createsubscriber
List pgsql-hackers
On Wed, Nov 19, 2025 at 02:49:29PM -0500, Robert Haas wrote:
> On Thu, Nov 13, 2025 at 7:46 AM Alena Vinter <dlaaren8@gmail.com> wrote:
>> The root cause is that `pg_createsubscriber` leaves behind recovery
>> parameters that interfere with the new standby's startup process,
>> causing recovery to stop before reaching a consistency point.
>
> Yes, I agree this is a much better scenario to test. Thanks.

Robert, does this line of arguments address the concerns you had
upthread?  Or do you still see a reason why not cleaning up these
recovery parameters would not be a good idea?

I don't see a strong need for a backpatch here as the approach I have
mentioned with a secondary configuration file, and an
include_if_exists would be a kind of design change for the tool
itself.  So this would qualify as a HEAD-only thing, if of course
you wouldd agree with the change to clean up the recovery parameters.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Resetting recovery target parameters in pg_createsubscriber
Next
From: Amit Kapila
Date:
Subject: Re: How can end users know the cause of LR slot sync delays?