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

From Michael Paquier
Subject Re: Resetting recovery target parameters in pg_createsubscriber
Date
Msg-id aUItOwhwx8YEtAzp@paquier.xyz
Whole thread Raw
In response to Re: Resetting recovery target parameters in pg_createsubscriber  (Andrey Rudometov <unlimitedhikari@gmail.com>)
List pgsql-hackers
On Sat, Dec 13, 2025 at 12:07:35PM +0700, Andrey Rudometov wrote:
> A patch with my approach to replacement is in attachments
> (to be applied after yours).
>
> p.s. I wonder why this builds at all - as far as I have tried, using
> BE in FE usually leads to a ton of compilation errors or, at least,
> warnings treated as errors - p.e, in this case backend definition
> uses ereport(), which does not work in frontend utilities.

Yep, that's indeed something that the patch should not do at all.

> -            durable_rename(filename, filename_with_original_contents, FATAL);
> +            err = durable_rename(filename, filename_with_original_contents);
> +            if (err)
> +                pg_fatal("could not rename file \"%s\"", filename);

I don't see a point in re-emitting an error message as well as you are
suggesting here.  durable_rename() does this job already on failure
with a set of pg_log_error().  The only difference is that pg_fatal()
is a shortcut for pg_log_error()+exit().
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Dilip Kumar
Date:
Subject: Re: Replace is_publishable_class() with relispublishable column in pg_class
Next
From: Michael Paquier
Date:
Subject: Re: [Proposal] Expose internal MultiXact member count function for efficient monitoring