Re: Logical Replication: SELECT pg_catalog.set_config Statement

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Hannes Kühtreiber <h(dot)kuehtreiber(at)synedra(dot)com>
Cc: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: Logical Replication: SELECT pg_catalog.set_config Statement
Date: 2021-05-18 12:24:17
Message-ID: 3044864.1621340657@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

=?UTF-8?Q?Hannes_K=c3=bchtreiber?= <h(dot)kuehtreiber(at)synedra(dot)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(at)10(dot)139(dot)0(dot)41 <mailto:usztestlogrepsub(at)10(dot)139(dot)0(dot)41>: LOG: statement: SELECT pg_catalog.set_config('search_path', '', false);
> 2021-05-17 16:08:03.596 CEST -usztestlogrepsub(at)10(dot)139(dot)0(dot)41 <mailto:usztestlogrepsub(at)10(dot)139(dot)0(dot)41>: LOG: received replication command: 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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Franck Routier (perso) 2021-05-18 12:52:02 Any insights on Qlik Sense using CURSOR ?
Previous Message Drouvot, Bertrand 2021-05-18 11:26:38 Re: [UNVERIFIED SENDER] Re: pg_upgrade can result in early wraparound on databases with high transaction load