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