Hi Amit,
On Fri, 11 Oct 2019 at 08:06, Amit Langote <amitlangot...@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 still replicated, just that a select
count from parent table shows 0, rest of the partitions including default
one has the data 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.
--
Regards,
Rafia Sabih
-- publisher
create table t (i int, j int, k text) partition by range(i);
create table child1 partition of t for values from ( 1) to (100);
create table child2 partition of t for values from (100) to (200);
create table child3 partition of t for values from (200) to (300);
create table child4 partition of t for values from (300) to (400);
create table child5 partition of t for values from (400) to (500);
create table def partition of t DEFAULT;
create publication mypub;
alter publication mypub add table t;
insert into t values (generate_series(1,500), generate_series(1,500),
repeat('jqbsuyt7832edjw', 20));
--subscriber
create table t (i int, j int, k text);
create table child1 (i int, j int, k text);
create table child5 (i int, j int, k text);
create table child4 (i int, j int, k text);
create table child3 (i int, j int, k text);
create table child2 (i int, j int, k text);
create table def (i int, j int, k text);
create subscription mysub connection 'host=localhost port=5432 dbname=postgres'
publication mypub;
