Re: base backup client as auxiliary backend process

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

In response to

Browse pgsql-hackers by date

  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