From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Alyona Vinter <dlaaren8(at)gmail(dot)com> |
Cc: | Alexander Korotkov <aekorotkov(at)gmail(dot)com>, "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Resetting recovery target parameters in pg_createsubscriber |
Date: | 2025-09-19 01:08:02 |
Message-ID: | aMys8vPrgEpWpc1m@paquier.xyz |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Sep 16, 2025 at 05:27:43PM +0700, Alyona Vinter wrote:
>> This patch also means that pg_createsubscriber is written so as the
>> contents added to recovery.conf/postgresql.auto.conf by
>> setup_recovery() are never reset if there is a failure in-flight. Is
>> that OK or should we also have an exit callback to do the cleanup work
>> in such cases?
>
> It's a good idea to add an exit callback. Additionally, I'd like to propose
> adding a pre-flight check at the start. This check would look for any
> existing recovery configuration that might be an artifact from a previous
> aborted run and warn the user or handle it appropriately. What do you think
> about implementing both the exit callback and the pre-flight check?
I am not sure how much a pre-flight check would help if we have an
exit callback that would make sure that things are cleaned up on exit.
Is there any need to worry about a kill(9) that would cause the exit
cleanup callback to not be called? We don't bother about that
usually, so I don't see a strong case for it here, either. :)
Alexander may have a different opinion.
> I will work on improving the code and will also add the documentation notes
> that Michael has pointed out ASAP.
Thanks.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Jonathan S. Katz | 2025-09-19 01:12:15 | Having postgresql.org link to cgit instead of gitweb |
Previous Message | Michael Paquier | 2025-09-19 01:02:00 | Re: PgStat_HashKey padding issue when passed by reference |