RE: speed up a logical replica setup
| От | Hayato Kuroda (Fujitsu) |
|---|---|
| Тема | RE: speed up a logical replica setup |
| Дата | |
| Msg-id | TY3PR01MB9889593399165B9A04106741F5662@TY3PR01MB9889.jpnprd01.prod.outlook.com обсуждение исходный текст |
| Ответ на | Re: speed up a logical replica setup ("Euler Taveira" <euler@eulerto.com>) |
| Ответы |
Re: speed up a logical replica setup
|
| Список | pgsql-hackers |
Dear Euler,
I love your proposal, so I want to join the review. Here are my first comments.
01.
Should we restrict that `--subscriber-conninfo` must not have hostname or IP?
We want users to execute pg_subscriber on the target, right?
02.
When the application was executed, many outputs filled my screen. Some of them
were by pg_subscriber, and others were server log. Can we record them into
separated file? I imagined like pg_upgrade.
03.
A replication command is used when replication slots are created. Is there a
reason to use it? I think we do not have to use logical replication walsender mode,
we can use an SQL function instead. pg_create_logical_replication_slot() also outputs
LSN, isn't it sufficient?
04.
As you know, there are several options for publications/subscriptions/replication
slots. Do you have a good way to specify them in your mind?
05.
I found that the connection string for each subscriptions have a setting
"fallback_application_name=pg_subscriber". Can we remove it?
```
postgres=# SELECT subconninfo FROM pg_subscription;
subconninfo
---------------------------------------------------------------------------------
user=postgres port=5431 fallback_application_name=pg_subscriber dbname=postgres
(1 row)
```
Best Regards,
Hayato Kuroda
FUJITSU LIMITED
В списке pgsql-hackers по дате отправления: