| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Alena Vinter <dlaaren8(at)gmail(dot)com>, Alexander Korotkov <aekorotkov(at)gmail(dot)com>, Ilyasov Ian <ianilyasov(at)outlook(dot)com>, "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Resetting recovery target parameters in pg_createsubscriber |
| Date: | 2025-12-03 05:11:39 |
| Message-ID: | aS_Gi_7pACVcg0sX@paquier.xyz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2025-12-03 05:28:41 | Re: How can end users know the cause of LR slot sync delays? |
| Previous Message | Michael Paquier | 2025-12-03 05:08:12 | Re: Resetting recovery target parameters in pg_createsubscriber |