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

From Robert Haas
Subject Re: Resetting recovery target parameters in pg_createsubscriber
Date
Msg-id CA+TgmoaveCRuuBA86K_ieW5vk0gPb2x-FDmm=K3e1YMV=7bPcw@mail.gmail.com
Whole thread Raw
In response to Re: Resetting recovery target parameters in pg_createsubscriber  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
On Wed, Dec 3, 2025 at 12:11 AM Michael Paquier <michael@paquier.xyz> wrote:
> 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.

As I see it, there's no bug here, because I don't think we've made any
promise to the user that they don't need to check what recovery
parameters are configured before running recovery. However, your
proposal seems like it could make life more convenient for users,
which seems like a good thing to do. The revised test case doesn't, in
my opinion, represent a scenario that absolutely has to work without
user intervention, but it's nicer if it does. So, I would see
committing this as a feature improvement but not back-patching it as a
reasonable way forward.

--
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: apply_scanjoin_target_to_paths and partitionwise join
Next
From: Greg Burd
Date:
Subject: Re: Refactor how we form HeapTuples for CatalogTuple(Insert|Update)