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

From Ajin Cherian
Subject Re: Excessive number of replication slots for 12->14 logical replication
Date
Msg-id CAFPTHDZBs98Vn9OBf=x1tAo_3bTY9wnvRrRX1KMYfMqu+Pngng@mail.gmail.com
Whole thread Raw
In response to RE: Excessive number of replication slots for 12->14 logical replication  ("houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.com>)
Responses Re: Excessive number of replication slots for 12->14 logical replication  (Peter Smith <smithpb2250@gmail.com>)
List pgsql-bugs
On Mon, Jul 25, 2022 at 7:48 PM houzj.fnst@fujitsu.com
<houzj.fnst@fujitsu.com> wrote:
>
> On Sunday, July 24, 2022 4:17 PM Ajin Cherian <itsajin@gmail.com> wrote:
> I tried the patch and confirmed that we won't get the ERROR "could not find
> free replication state slot for replication origin with OID" again after
> applying the patch.
>
> I tested the patch by letting the apply worker wait for a bit more time after
> setting the state to SUBREL_STATE_CATCHUP. In this case(before the patch) the
> table sync worker will exit before the apply worker drop the replorigin, and
> the apply worker will try to start another worker which would cause the
> ERROR(before the patch).

Thanks for testing the patch.

>
> Few comments:
>
> 1)
> -                                * There is a chance that the user is concurrently performing
> -                                * refresh for the subscription where we remove the table
> -                                * state and its origin and by this time the origin might be
> -                                * already removed. So passing missing_ok = true.
> -                                */
>
> I think it would be better if we can move these comments to the new place where
> we drop the replorigin.

Fixed this.


>
> 2)
>
> -                               replorigin_drop_by_name(originname, true, false);
>
>                                 /*
>                                  * Update the state to READY only after the origin cleanup.
>
> Do we need to slightly modify the comment here as the origin drop code has been
> moved to other places. Maybe "It's safe to update the state to READY as the
> origin should have been dropped by table sync worker".
>

Fixed this.
Added an updated patch.

regards,
Ajin Cherian
Fujitsu Australia

Attachment

pgsql-bugs by date:

Previous
From: "houzj.fnst@fujitsu.com"
Date:
Subject: RE: Excessive number of replication slots for 12->14 logical replication
Next
From: David Steele
Date:
Subject: Re: could not link file in wal restore lines