Re: Logical Replication: SELECT pg_catalog.set_config Statement

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Logical Replication: SELECT pg_catalog.set_config Statement
Дата
Msg-id 3044864.1621340657@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Logical Replication: SELECT pg_catalog.set_config Statement  (Hannes Kühtreiber <h.kuehtreiber@synedra.com>)
Ответы Re: Logical Replication: SELECT pg_catalog.set_config Statement  (Hannes Kühtreiber <h.kuehtreiber@synedra.com>)
Список pgsql-general
=?UTF-8?Q?Hannes_K=c3=bchtreiber?= <h.kuehtreiber@synedra.com> writes:
> We have tried logical replication in a test-setup, and it appears to
> work fine.
> However, the following statement keeps running:

> SELECT pg_catalog.set_config('search_path', '', false);

What makes you think it "keeps running"?  It looks to me like the
replication client does that and then goes about its business:

> 2021-05-17 16:08:03.595 CEST -usztestlogrepsub@10.139.0.41  <mailto:usztestlogrepsub@10.139.0.41>: LOG:  statement:
SELECTpg_catalog.set_config('search_path', '', false); 
> 2021-05-17 16:08:03.596 CEST -usztestlogrepsub@10.139.0.41  <mailto:usztestlogrepsub@10.139.0.41>: LOG:  received
replicationcommand: IDENTIFY_SYSTEM 

Admittedly, since you seem to have omitted the PID from your
log_line_prefix, it's hard to be 100% sure that these log entries
are from the same process.  But I bet they are.  The standard
walreceiver definitely does things this way.

In short, I think there's nothing to see here.

            regards, tom lane



В списке pgsql-general по дате отправления:

Предыдущее
От: Hannes Kühtreiber
Дата:
Сообщение: Logical Replication: SELECT pg_catalog.set_config Statement
Следующее
От: "Franck Routier (perso)"
Дата:
Сообщение: Any insights on Qlik Sense using CURSOR ?