Logical Replication: SELECT pg_catalog.set_config Statement

From: Hannes Kühtreiber <h(dot)kuehtreiber(at)synedra(dot)com>
To: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Logical Replication: SELECT pg_catalog.set_config Statement
Date: 2021-05-18 09:29:38
Message-ID: 8e974635-8048-4e28-8c42-62248dcac9b5@synedra.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hello everybody,

not sure where to post this, general seems most appropriate.

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);

It is issued by the user 'subscriber' we have created for the subscription. Originally it only had the 'Replication' role, but we have subsequently made it Superuser.
However, the behaviour is the same.

List of roles
Role name | Attributes | Member of
------------+------------------------------------------------+-----------
postgres | Superuser, Create role, Create DB, Replication | {}
subscriber | Superuser, Replication | {}

Strangely, when I log in as subscriber and query the searchpath, the result is 'public'
I can then execute the above statement, and it sets the search_path to ''

At the next restart, the statement pops up again, and hangs ....
Here is the log:
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
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: START_REPLICATION SLOT "usztestlogrepsub" LOGICAL E51/EC041228 (proto_version '1', publication_names '"usztestlogreppub"')
2021-05-17 16:08:03.597 CEST -usztestlogrepsub(at)10(dot)139(dot)0(dot)41 <mailto:usztestlogrepsub(at)10(dot)139(dot)0(dot)41>: LOG: starting logical decoding for slot "usztestlogrepsub"
2021-05-17 16:08:03.597 CEST -usztestlogrepsub(at)10(dot)139(dot)0(dot)41 <mailto:usztestlogrepsub(at)10(dot)139(dot)0(dot)41>: DETAIL: Streaming transactions committing after E51/EC06B668, reading WAL from E51/EC06B668.
2021-05-17 16:08:03.597 CEST -usztestlogrepsub(at)10(dot)139(dot)0(dot)41 <mailto:usztestlogrepsub(at)10(dot)139(dot)0(dot)41>: LOG: logical decoding found consistent point at E51/EC06B668
2021-05-17 16:08:03.597 CEST -usztestlogrepsub(at)10(dot)139(dot)0(dot)41 <mailto:usztestlogrepsub(at)10(dot)139(dot)0(dot)41>: DETAIL: There are no running transactions.

Can anybody explain why this happens, and how to avoid it?

regards
Hannes

--

Responses

Browse pgsql-general by date

  From Date Subject
Next 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
Previous Message Ben Hoskings 2021-05-18 07:46:19 Re: Occasional lengthy locking causing stalling on commit