Re: adding partitioned tables to publications - Mailing list pgsql-hackers

From Amit Langote
Subject Re: adding partitioned tables to publications
Date
Msg-id CA+HiwqFm1Hv3PT+6=MRDZyeShJrob9-FxsiOkSS6=j6kFxu9sQ@mail.gmail.com
Whole thread Raw
In response to Re: adding partitioned tables to publications  (Rafia Sabih <rafia.pghackers@gmail.com>)
List pgsql-hackers
Hello Rafia,

On Tue, Nov 5, 2019 at 12:41 AM Rafia Sabih <rafia.pghackers@gmail.com> wrote:
> On Fri, 11 Oct 2019 at 08:06, Amit Langote <amitlangote09@gmail.com> wrote:
>> Thanks for sharing this case.  I hadn't considered it, but you're
>> right that it should be handled sensibly.  I have fixed table sync
>> code to handle this case properly.  Could you please check your case
>> with the attached updated patch?
>>
> I was checking this today and found that the behavior doesn't change much with the updated patch. The tables are
stillreplicated, just that a select count from parent table shows 0, rest of the partitions including default one has
thedata from the publisher. I was expecting more like an error at subscriber saying the table type is not same. 
>
> Please find the attached file for the test case, in case something is unclear.

Thanks for the test case.

With the latest patch I posted, you'll get the following error on subscriber:

create subscription mysub connection 'host=localhost port=5432
dbname=postgres' publication mypub;
ERROR:  cannot use relation "public.t" as logical replication target
DETAIL:  "public.t" is a regular table on subscription side whereas a
partitioned table on publication side

Although to be honest, I'd rather not see the error.  As I mentioned
in my email earlier, it'd be nice to be able sync a partitioned table
and a regular table (or vice versa) via replication.

Thanks,
Amit



pgsql-hackers by date:

Previous
From: Amit Khandekar
Date:
Subject: Re: Minimal logical decoding on standbys
Next
From: Amit Kapila
Date:
Subject: Re: dropdb --force