Re: Resetting recovery target parameters in pg_createsubscriber

Michael Paquier <michael@paquier.xyz>

From: Michael Paquier <michael@paquier.xyz>
To: Andrey Rudometov <unlimitedhikari@gmail.com>
Cc: Alena Vinter <dlaaren8@gmail.com>, Alexander Korotkov <aekorotkov@gmail.com>, Robert Haas <robertmhaas@gmail.com>, Ilyasov Ian <ianilyasov@outlook.com>, "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2025-12-17T04:10:35Z
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 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