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 по дате отправления: