|From:||Sergei Kornilov <sk(at)zsrv(dot)org>|
|To:||Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>|
|Subject:||Re: base backup client as auxiliary backend process|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
>> 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?
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.
|Next Message||Jeevan Chalke||2019-07-11 11:30:22||Re: block-level incremental backup|
|Previous Message||Kyotaro Horiguchi||2019-07-11 10:56:10||Re: progress report for ANALYZE|