Horton

Re: Resetting recovery target parameters in pg_createsubscriber

Michael Paquier <michael@paquier.xyz>

View thread
From: Michael Paquier <michael@paquier.xyz>
To: Robert Haas <robertmhaas@gmail.com>
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-03T05:11:39Z
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, 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