Re: BUG #17670: Logical Replication data may be lost on the subscription under certain scenarios

From: Japin Li <japinli(at)hotmail(dot)com>
To: Dilip Kumar <dilipbalaut(at)gmail(dot)com>
Cc: xyh(at)nvn(dot)xyz, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #17670: Logical Replication data may be lost on the subscription under certain scenarios
Date: 2022-10-30 13:52:26
Message-ID: MEYP282MB1669BC0FA76F44DA184FD0B3B6349@MEYP282MB1669.AUSP282.PROD.OUTLOOK.COM
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs


On Sun, 30 Oct 2022 at 14:39, Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
> On Fri, Oct 28, 2022 at 8:07 PM Japin Li <japinli(at)hotmail(dot)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.

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Lauri Laanmets 2022-10-30 17:13:36 Memory leak on subquery as scalar operand
Previous Message Erki Eessaar 2022-10-30 10:15:32 Problem with Avg function and Money type in PostgreSQL 15