Horton

Re: base backup client as auxiliary backend process

Sergei Kornilov <sk@zsrv.org>

View thread View on postgr.es
From: Sergei Kornilov <sk@zsrv.org>
To: Thomas Munro <thomas.munro@gmail.com>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2019-07-11T11:12:36Z
Lists: pgsql-hackers 
Hello

>>  Attached is a very hackish patch to implement this. It works like this:
>>
>>      # (assuming you have a primary already running somewhere)
>>      initdb -D data2 --minimal
>>      $EDITOR data2/postgresql.conf # set primary_conninfo
>>      pg_ctl -D data2 start
>
> +1, very nice. How about --replica?

+1

Also not works with -DEXEC_BACKEND for me.

> There is also the question what you do
> if the base backup fails halfway through. Currently you probably need
> to delete the whole data directory and start again with initdb. Better
> might be a way to start again and overwrite any existing files, but that
> can clearly also be dangerous.

I think the need for delete directory and rerun initdb is better than overwrite files.

- we need check major version. Basebackup can works with different versions, but would be useless to copying cluster which we can not run
- basebackup silently overwrite configs (pg_hba.conf, postgresql.conf, postgresql.auto.conf) in $PGDATA. This is ok for pg_basebackup but not for backend process
- I think we need start walreceiver. At best, without interruption during startup replay (if possible)

> XXX Is there a use for
> 		 * switching into (non-standby) recovery here?

I think not.

regards, Sergei

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