Re: base backup client as auxiliary backend process - Mailing list pgsql-hackers

From Alexandra Wang
Subject Re: base backup client as auxiliary backend process
Date
Msg-id CACiyaSqci=MhdEwVZEf=tUOdHfoEZPK9330ajhg5b750nPEenw@mail.gmail.com
Whole thread Raw
In response to Re: base backup client as auxiliary backend process  (Michael Paquier <michael@paquier.xyz>)
Responses Re: base backup client as auxiliary backend process
List pgsql-hackers
Hi Peter,

On Fri, Nov 22, 2019 at 6:22 PM Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote:
Here is another patch set that implements the temporary slot use on the
walreceiver side, essentially mirroring what pg_basebackup already does.

I think this patch set might be useful on its own, even without the base
backup stuff to follow.

I very much like this idea of every replication connection should have a
replication slot, either permanent or temporary if user didn't specify. I agree
that this patch is useful on its own.

> This makes a whole bunch of things much nicer: The connection
> information for where to get the base backup from comes from
> postgresql.conf, so you only need to specify it in one place.
> pg_basebackup is completely out of the picture; no need to deal with
> command-line options, --recovery-conf, screen, monitoring for
> completion, etc.  If something fails, the base backup process can
> automatically be restarted (maybe).  Operating system integration is
> much easier: You only call initdb and then pg_ctl or postgres, as you
> are already doing.  Automated deployment systems don't need to wait for
> pg_basebackup to finish: You only call initdb, then start the server,
> and then you're done -- waiting for the base backup to finish can be
> done by the regular monitoring system.

Back to the base backup stuff, I don't quite understand all the benefits you
mentioned above. It seems to me the greatest benefit with this patch is that
postmaster takes care of pg_basebackup itself, which reduces the human wait in
between running the pg_basebackup and pg_ctl/postgres commands. Is that right?
I personally don't mind the --write-recovery-conf option because it helps me
write the primary_conninfo and primary_slot_name gucs into
postgresql.auto.conf, which to me as a developer is easier than editing
postgres.conf without automation.  Sorry about the dumb question but what's so
bad about --write-recovery-conf?  Are you planning to completely replace
pg_basebackup with this? Is there any use case that a user just need a
basebackup but not immediately start the backend process?

Also the patch doesn't apply to master any more, need a rebase.

--
Alexandra

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: logical decoding : exceeded maxAllocatedDescs for .spill files
Next
From: ilmari@ilmari.org (Dagfinn Ilmari Mannsåker)
Date:
Subject: Re: Fixing parallel make of libpq