Horton

Re: Resetting recovery target parameters in pg_createsubscriber

Robert Haas <robertmhaas@gmail.com>

View thread
From: Robert Haas <robertmhaas@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Alena Vinter <dlaaren8@gmail.com>, Alexander Korotkov <aekorotkov@gmail.com>, Ilyasov Ian <ianilyasov@outlook.com>, "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2025-12-03T14:08:42Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. pg_createsubscriber: Improve handling of automated recovery configuration

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