From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
---|---|
To: | Alexandra Wang <lewang(at)pivotal(dot)io> |
Cc: | Sergei Kornilov <sk(at)zsrv(dot)org>, Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: base backup client as auxiliary backend process |
Date: | 2020-01-15 15:20:35 |
Message-ID: | 32bfb247-f65c-fb29-e062-f4f8f939d12a@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2020-01-15 15:23:22 | Re: Complete data erasure |
Previous Message | Peter Eisentraut | 2020-01-15 15:17:29 | Re: base backup client as auxiliary backend process |