Re: Re: row filtering for logical replication - Mailing list pgsql-hackers

From movead.li@highgo.ca
Subject Re: Re: row filtering for logical replication
Date
Msg-id 2019092609383745473827@highgo.ca
Whole thread Raw
In response to row filtering for logical replication  (Euler Taveira <euler@timbira.com.br>)
List pgsql-hackers

>Which regression?
Apply the 0001.patch~0005.patch and then do a 'make check', then there be a
failed item. And when you apply the 0006.patch, the failed item disappeared.

>There should be an error because you don't have a PK or REPLICA IDENTITY.
No. I have done the 'ALTER TABLE cities  REPLICA IDENTITY FULL'.

>Even if you create a PK or REPLICA IDENTITY, it won't turn this UPDATE
>into a INSERT and send it to the other node (indeed UPDATE will be
>sent however there isn't a tuple to update). Also, filter columns must
>be in PK or REPLICA IDENTITY. I explain this in documentation.
You should considered the Result2:
     On publication:
      insert into cities values('t1',1,135);
      update cities set altitude=300 where altitude=135;
      postgres=# table cities ;
       name | population | altitude 
      ------+------------+----------
       t1   |        123 |      134
       t1   |          1 |      300
      (2 rows)
      
      On subscription:
      ostgres=# table cities ;
       name | population | altitude 
      ------+------------+----------
       t1   |          1 |      135

The tuple ('t1',1,135) appeared in both publication and subscription,
but after an update on publication, the tuple is disappeared on 
publication and change nothing on subscription.

The same with Result1, they puzzled me today and I think they will
puzzle the users in the future. It should have a more wonderful design,
for example, a log to notify users that there be a problem during replication
at least.

---
Highgo Software (Canada/China/Pakistan) 
URL : www.highgo.ca 
EMAIL: mailto:movead(dot)li(at)highgo(dot)ca
 
 
 
 

pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: CVE-2017-7484-induced bugs, or, btree cmp functions are not leakproof?
Next
From: Kyotaro Horiguchi
Date:
Subject: A comment fix in xlogreader.c