Re: Enhance pg_createsubscriber to create required standby.

On Wed, Jun 04, 2025 at 03:26:24PM +0530, Amit Kapila wrote:
> On Wed, Jun 4, 2025 at 2:39 PM Peter Eisentraut <peter@eisentraut.org> wrote:
>> It's not clear to me how this change now would substantially improve the
>> user experience.  The number of characters you type is approximately the
>> same.  You still need to support the old mode because the backup might
>> not come from pg_basebackup.
>
> In the current functionality, the user must first manually create a
> standby or use an existing standby to make it a subscriber. I thought
> saving this step for users would be quite helpful. It also helps
> streamline the process into a single, cohesive workflow.

+    appendPQExpBuffer(pg_basebackup_cmd, "\"%s\" -d", pg_basebackup_path);
+    appendShellString(pg_basebackup_cmd, opt->pub_conninfo_str);
+    appendPQExpBufferStr(pg_basebackup_cmd, " -D ");
+    appendShellString(pg_basebackup_cmd, standby_dir);
+    appendPQExpBufferStr(pg_basebackup_cmd, " -P -X stream -R");

The proposed patch generates internally one single pg_basebackup
command that it thinks would be good enough for normal cases, but
pg_basebackup is able to do so much more lately in terms of formats,
client-side compression and server-side compression that I fear we are
going to need to provide an extra option for pg_createsubscriber to be
able to pass a list of options to it, or provide equivalents of what
pg_basebackup is doing.  If we do that, then we'll need to worry about
providing correct quoting for the options given to the command line of
pg_createsubscriber, which can be easily itchy especially on WIN32
when passing commands to a command prompt.

I'd rather not go this way, keeping one tool for each job.  The
arguments about the possibility to do an automated cleanup of a data
folder when creating a subscriber in one step's failure or the
possibility to embed a pg_resetwal command that reinitializes a system
ID are IMO too thin to justify the potential maintenance cost that we
would have to bear should pg_basebackup be made more complex in the
future.  pg_basebackup becoming more complex means that
pg_createsubscriber would need to cope with the facilities added to
the former.

In short, I don't think that this patch is a good idea.
--
Michael