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

From Andrey Rudometov
Subject Re: Resetting recovery target parameters in pg_createsubscriber
Date
Msg-id CAF6JsWgRDGmUYAgvpmWqp4Kc_PNYBb9R8kVsDeJgnom3haZjkw@mail.gmail.com
Whole thread Raw
In response to Re: Resetting recovery target parameters in pg_createsubscriber  (Alena Vinter <dlaaren8@gmail.com>)
Responses Re: Resetting recovery target parameters in pg_createsubscriber
List pgsql-hackers
Hello Alena!

As discussion here came to a halt, I want to add some
(counter)arguments, which may or may not make Michael's
proposal sound preferable to you.

On Mon, 10 Nov 2025 at 12:02, Alena Vinter <dlaaren8@gmail.com> wrote:
> I'm not in favor of saving additional files.

As far as I understand, there should be only one to two
additional files - it's not like they will multiply.
Some extensions can use additional files, so why
pg_createsubscriber couldn't?

> Therefore, it seems appropriate that they should be
> captured by the verbose/debug mode. If verbose mode
> isn't used, we lose more than just the recovery parameters

But if you save them as messages in server log, then user
might lose them even in verbose mode. Log is not stored
infinitely, and user may not have access to messages
if some time has passed after the incident. A file
seems to be a more reliable solution here.

P.s. About re-emitting error message with pg_fatal in my
proposal - I agree, simple exit() should suffice.

--
best regards,
Andrey Rudometov



pgsql-hackers by date:

Previous
From: Ashutosh Bapat
Date:
Subject: Re: Refactor replication origin state reset helpers
Next
From: sunil s
Date:
Subject: Avoid corrupting DefElem nodes when parsing publication_names and publish options