Re: Logical replication 'possible' problem - Mailing list pgsql-general

From Steve Baldwin
Subject Re: Logical replication 'possible' problem
Date
Msg-id CAKE1AiaSb4xfOtqHtkxoiKr5RPubmXiZ9FHX=jENKJ2pjp2SKw@mail.gmail.com
Whole thread Raw
In response to Logical replication 'possible' problem  (Steve Baldwin <steve.baldwin@gmail.com>)
Responses Re: Logical replication 'possible' problem
List pgsql-general
Sorry, I should have added the publisher is on 13.1 and the subscriber 14.2. Both are AWS RDS instances. I checked the log files for the publisher and subscriber and couldn't see any logical replication errors. The publisher is a busy DB though so if there are any errors there, I may have missed them.

Thanks.

On Wed, May 4, 2022 at 1:50 PM Steve Baldwin <steve.baldwin@gmail.com> wrote:
Hi,

I'm in the process of doing the initial syncing of a subscriber with a publisher.

There is only one table that is still in a 'dumping' state. It is quite a large table and in previous executions it took several hours.

I'm not sure if it encountered a problem and stopped or if it is still going.

Looking at the replication slots on the publisher I see this:

b2bcreditonline=> select slot_name, active, active_pid from pg_replication_slots;
                 slot_name                  | active | active_pid
--------------------------------------------+--------+------------
 b2bcreditonline_prod_b_master              | t      |      21511
 b2bcreditonline_prod_b_shard               | t      |      21703
 pg_67491625_sync_60067_7093664237039303581 | f      |
(3 rows)

I assume the pg_xxxx slot is the one created for the initial copy but I'm not sure if having a false active state is normal/ok.

If it is, great. If not, how do I determine the problem and go about fixing it?

Thanks,

Steve

pgsql-general by date:

Previous
From: Steve Baldwin
Date:
Subject: Logical replication 'possible' problem
Next
From: Steve Baldwin
Date:
Subject: Re: Logical replication 'possible' problem