Re: speed up a logical replica setup
| От | Euler Taveira |
|---|---|
| Тема | Re: speed up a logical replica setup |
| Дата | |
| Msg-id | 247c68ad-dda9-469e-8f1e-213167be00b2@www.fastmail.com обсуждение исходный текст |
| Ответ на | Re: speed up a logical replica setup (Andres Freund <andres@anarazel.de>) |
| Список | 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 waytoo easily get into situations trying to apply WAL from different systems toeach 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. Perhapswith 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.
В списке pgsql-hackers по дате отправления: