On Wed, Jan 6, 2021 at 2:13 PM Peter Smith <smithpb2250@gmail.com> wrote:
>
> I think it makes sense. If there can be a race between the tablesync
> re-launching (after error), and the AlterSubscription_refresh removing
> some table’s relid from the subscription then there could be lurking
> slot/origin tablesync resources (of the removed table) which a
> subsequent DROP SUBSCRIPTION cannot discover. I will think more about
> how/if it is possible to make this happen. Anyway, I suppose I ought
> to refactor/isolate some of the tablesync cleanup code in case it
> needs to be commonly called from DropSubscription and/or from
> AlterSubscription_refresh.
>
Fair enough. BTW, I have analyzed whether we need any modifications to
pg_dump/restore for this patch as this changes the state of one of the
fields in the system table and concluded that we don't need any
change. For subscriptions, we don't dump any of the information from
pg_subscription_rel, rather we just dump subscriptions with the
connect option as false which means users need to enable the
subscription and refresh publication after restore. I have checked
this in the code and tested it as well. The related information is
present in pg_dump doc page [1], see from "When dumping logical
replication subscriptions ....".
[1] - https://www.postgresql.org/docs/devel/app-pgdump.html
--
With Regards,
Amit Kapila.