Re: base backup client as auxiliary backend process

Поиск
Список
Период
Сортировка
От Alexandra Wang
Тема Re: base backup client as auxiliary backend process
Дата
Msg-id CACiyaSqci=MhdEwVZEf=tUOdHfoEZPK9330ajhg5b750nPEenw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: base backup client as auxiliary backend process  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: base backup client as auxiliary backend process
Список 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 по дате отправления:

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: logical decoding : exceeded maxAllocatedDescs for .spill files
Следующее
От: ilmari@ilmari.org (Dagfinn Ilmari Mannsåker)
Дата:
Сообщение: Re: Fixing parallel make of libpq