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 <pe...@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.
+1
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
