Re: Excessive number of replication slots for 12->14 logical replication - Mailing list pgsql-bugs

From vignesh C
Subject Re: Excessive number of replication slots for 12->14 logical replication
Date
Msg-id CALDaNm07QRB+F2aq5hvb-MoHrBEWih0HdR0S1-n6PjP2e2SR8w@mail.gmail.com
Whole thread Raw
In response to Re: Excessive number of replication slots for 12->14 logical replication  (Bowen Shi <zxwsbg12138@gmail.com>)
Responses RE: Excessive number of replication slots for 12->14 logical replication  ("Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>)
List pgsql-bugs
On Thu, 18 Jan 2024 at 13:00, Bowen Shi <zxwsbg12138@gmail.com> wrote:
>
> Dears,
>
> I encountered a similar problem when I used logical replication to replicate databases from pg 16 to pg 16.
>
> I started 3 subscription in parallel, and  subscriber's postgresql.conf is following:
> max_replication_slots = 10
> max_sync_workers_per_subscription = 2
>
> However, after 3 minutes, I found three COPY errors in subscriber:
> "error while shutting down streaming COPY: ERROR:  could not find record while sending logically-decoded data:
missingcontrecord at xxxx/xxxxxxxxx"" 
> Then,  the subscriber began to print a large number of errors: "could not find free replication state slot for
replicationorigin with ID 11, Increase max_replication_slots and try again." 
>
> And the publisher was full of pg_xxx_sync_xxxxxxx slots, printing lots of "all replication slots are in use, Free one
orincrease max_replication_slots." 
>
> This question is very similar to https://www.postgresql.org/message-id/flat/20220714115155.GA5439%40depesz.com . When
thetable sync worker encounters an error and exits while copying a table, the replication origin will not be deleted.
Andnew table sync workers would create sync slot in the publisher and then exit without dropping them. 

I had tried various tests with the suggested configuration, but I did
not hit this scenario. I was able to simulate this problem with a
lesser number of max_replication_slots, but the behavior is as
expected in this case.
If you have a test case or logs for this, can you share it please. It
will be easier to generate the sequence of things that is happening
and to project a clear picture of what is happening.

Regards,
Vignesh



pgsql-bugs by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: error when having sub statements with fields that do not exist
Next
From: Andrey Borodin
Date:
Subject: Re: [BUG] false positive in bt_index_check in case of short 4B varlena datum