Horton

Re: base backup client as auxiliary backend process

Peter Eisentraut <peter.eisentraut@2ndquadrant.com>

View thread View on postgr.es
From: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
To: Alexandra Wang <lewang@pivotal.io>
Cc: Sergei Kornilov <sk@zsrv.org>, Michael Paquier <michael@paquier.xyz>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2020-01-15T15:20:35Z
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

Commits

  1. Factor out InitControlFile() from BootStrapXLOG()

  2. Reformat code comment

  3. pg_resetwal: Rename function to avoid potential conflict

  4. Expose PQbackendPID() through walreceiver API

  5. walreceiver uses a temporary replication slot by default

  6. Make lsn argument of walrcv_create_slot() optional

  7. More precise errors from initial pg_control check