Re: speed up a logical replica setup - Mailing list pgsql-hackers

From Euler Taveira
Subject Re: speed up a logical replica setup
Date
Msg-id 247c68ad-dda9-469e-8f1e-213167be00b2@www.fastmail.com
Whole thread Raw
In response to Re: speed up a logical replica setup  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Mon, Feb 21, 2022, at 8:28 PM, Andres Freund wrote:
I think the system identifier should also be changed, otherwise you can way
too easily get into situations trying to apply WAL from different systems to
each other. Not going to end well, obviously.
Good point.

> This tool does not take a base backup. It can certainly be included later.
> There is already a tool do it: pg_basebackup.

It would make sense to allow to call pg_basebackup from the new tool. Perhaps
with a --pg-basebackup-parameters or such.
Yeah. I'm planning to do that in a near future. There are a few questions in my
mind. Should we call the pg_basebackup directly (like
pglogical_create_subscriber does) or use a base backup machinery to obtain the
backup? If we choose the former, it should probably sanitize the
--pg-basebackup-parameters to allow only a subset of the command-line options
(?). AFAICS the latter requires some refactors in the pg_basebackup code --
e.g. expose at least one function (BaseBackup?) that accepts a struct of
command-line options as a parameter and returns success/failure. Another
possibility is to implement a simple BASE_BACKUP command via replication
protocol. The disadvantages are: (a) it could duplicate code and (b) it might
require maintenance if new options are added to the BASE_BACKUP command.


--
Euler Taveira

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: speed up a logical replica setup
Next
From: Fujii Masao
Date:
Subject: Re: postgres_fdw: using TABLESAMPLE to collect remote sample