Re: row filtering for logical replication

From: movead li <movead(dot)li(at)highgo(dot)ca>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Cc: Euler Taveira <euler(at)timbira(dot)com(dot)br>
Subject: Re: row filtering for logical replication
Date: 2019-09-23 04:59:02
Message-ID: 156921474237.1442.4182373664494053231.pgcf@coridan.postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello

I find several problems as below when I test the patches:

1. There be some regression problem after apply 0001.patch~0005.patch
The regression problem is solved in 0006.patch
2. There be a data wrong after create subscription if the relation contains
inherits table, for example:
##########################
The Tables:
CREATE TABLE cities (
name text,
population float,
altitude int
);
CREATE TABLE capitals (
state char(2)
) INHERITS (cities);

Do on publication:
insert into cities values('aaa',123, 134);
insert into capitals values('bbb',123, 134);
create publication pub_tc for table cities where (altitude > 100 and altitude < 200);
postgres=# select * from cities ;
name | population | altitude
------+------------+----------
aaa | 123 | 134
bbb | 123 | 134
(2 rows)

Do on subscription:
create subscription sub_tc connection 'host=localhost port=5432 dbname=postgres' publication pub_tc;
postgres=# select * from cities ;
name | population | altitude
------+------------+----------
aaa | 123 | 134
bbb | 123 | 134
bbb | 123 | 134
(3 rows)
##########################
An unexcept row appears.

3. I am puzzled when I test the update.
Use the tables in problem 2 and test as below:
#########################
On publication:
postgres=# insert into cities values('t1',123, 34);
INSERT 0 1
postgres=# update cities SET altitude = 134 where altitude = 34;
UPDATE 1
postgres=# select * from cities ;
name | population | altitude
------+------------+----------
t1 | 123 | 134
(1 row)
On subscription:
postgres=# select * from cities ;
name | population | altitude
------+------------+----------
(0 rows)

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
(1 row)
#########################
Result1:Update a row that is not suitable the publication condition to
suitable, the subscription change nothing.
Result2: Update a row that is suitable for the publication condition to
not suitable, the subscription change nothing.
If it is a bug? Or there should be an explanation about it?

4. SQL splicing code in fetch_remote_table_info() function is too long

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

The new status of this patch is: Waiting on Author

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fabien COELHO 2019-09-23 06:28:49 Re: pgbench - allow to create partitioned tables
Previous Message Amit Kapila 2019-09-23 02:53:36 Re: pgbench - allow to create partitioned tables