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> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: base backup client as auxiliary backend process |
Date: | 2019-07-11 11:12:36 |
Message-ID: | 14121971562843556@sas1-adb97d30497b.qloud-c.yandex.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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
From | Date | Subject | |
---|---|---|---|
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 |