Re: Enhance pg_createsubscriber to create required standby.

On 2025-07-30 We 8:38 PM, Michael Paquier wrote:
> 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(at)eisentraut(dot)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.

+1

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com