Re: BUG #17670: Logical Replication data may be lost on the subscription under certain scenarios
От | Japin Li |
---|---|
Тема | Re: BUG #17670: Logical Replication data may be lost on the subscription under certain scenarios |
Дата | |
Msg-id | MEYP282MB1669BC0FA76F44DA184FD0B3B6349@MEYP282MB1669.AUSP282.PROD.OUTLOOK.COM обсуждение исходный текст |
Ответ на | Re: BUG #17670: Logical Replication data may be lost on the subscription under certain scenarios (Dilip Kumar <dilipbalaut@gmail.com>) |
Ответы |
Re: BUG #17670: Logical Replication data may be lost on the subscription under certain scenarios
|
Список | pgsql-bugs |
On Sun, 30 Oct 2022 at 14:39, Dilip Kumar <dilipbalaut@gmail.com> wrote: > On Fri, Oct 28, 2022 at 8:07 PM Japin Li <japinli@hotmail.com> wrote: > >> I can reproduce it on HEAD. Here is my analysis: >> >> When we rename the t_test1 to t_test2, the subscriber doesn't have a >> table matched publication table name, so the logical replication throw >> an error. Then, we create a new t_test1 on subscriber, the logical >> replication worker can find the table that matches the published name. >> However, the pg_subscription_rel hasn't updated, and when we try to get >> the subscription state through GetSubscriptionRelState(), it cannot find >> a matched subscription relation mapping, so the WAL cannot apply to the >> new table t_test1. > > I am just wondering if it is correct behavior to allow renaming the > table used by a subscription, or should there be some dependency? Maybe we can add a dependency to make the user know what they are doing. I also want to know when we should add a dependency? -- Regrads, Japin Li. ChengDu WenWu Information Technology Co.,Ltd.
В списке pgsql-bugs по дате отправления: