Re: base backup client as auxiliary backend process
От | Peter Eisentraut |
---|---|
Тема | Re: base backup client as auxiliary backend process |
Дата | |
Msg-id | 32bfb247-f65c-fb29-e062-f4f8f939d12a@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: base backup client as auxiliary backend process (Alexandra Wang <lewang@pivotal.io>) |
Список | pgsql-hackers |
On 2020-01-09 11:57, Alexandra Wang wrote: > 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? Making it easier to automate is one major appeal of my proposal. The current way of setting up a standby is very difficult to automate correctly. > 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? I'm not planning to replace or change pg_basebackup. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: