Re: row filtering for logical replication

From: Peter Smith <smithpb2250(at)gmail(dot)com>
To: vignesh C <vignesh21(at)gmail(dot)com>
Cc: "houzj(dot)fnst(at)fujitsu(dot)com" <houzj(dot)fnst(at)fujitsu(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Greg Nancarrow <gregn4422(at)gmail(dot)com>, "tanghy(dot)fnst(at)fujitsu(dot)com" <tanghy(dot)fnst(at)fujitsu(dot)com>, Ajin Cherian <itsajin(at)gmail(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Euler Taveira <euler(at)eulerto(dot)com>, Rahila Syed <rahilasyed90(at)gmail(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, Önder Kalacı <onderkalaci(at)gmail(dot)com>, japin <japinli(at)hotmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, David Steele <david(at)pgmasters(dot)net>, Craig Ringer <craig(at)2ndquadrant(dot)com>, Amit Langote <amitlangote09(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: row filtering for logical replication
Date: 2022-01-17 00:51:01
Message-ID: CAHut+Pvxy=Okx2k6+FyBK4WPZdsO5R3NFPBoXtO15fs2PAWLKw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Dec 2, 2021 at 7:40 PM vignesh C <vignesh21(at)gmail(dot)com> wrote:
>
...
>
> 2) testpub5 and testpub_syntax2 are similar, one of them can be removed:
> +SET client_min_messages = 'ERROR';
> +CREATE PUBLICATION testpub5 FOR TABLE testpub_rf_tbl1,
> testpub_rf_tbl2 WHERE (c <> 'test' AND d < 5);
> +RESET client_min_messages;
> +\dRp+ testpub5
>
> +SET client_min_messages = 'ERROR';
> +CREATE PUBLICATION testpub_syntax2 FOR TABLE testpub_rf_tbl1,
> testpub_rf_myschema.testpub_rf_tbl5 WHERE (h < 999);
> +RESET client_min_messages;
> +\dRp+ testpub_syntax2
> +DROP PUBLICATION testpub_syntax2;
>

To re-confirm my original motivation for adding the syntax2 test I
coded some temporary logging into the different PublicationObjSpec
cases. After I re-ran the regression tests, here are some extracts
from the postmaster.log:

(for testpub5)
2022-01-14 13:06:32.149 AEDT client backend[21853]
pg_regress/publication LOG: !!> TABLE relation_expr OptWhereClause
2022-01-14 13:06:32.149 AEDT client backend[21853]
pg_regress/publication STATEMENT: CREATE PUBLICATION testpub5 FOR
TABLE testpub_rf_tbl1, testpub_rf_tbl2 WHERE (c <> 'test' AND d < 5)
WITH (publish = 'insert');
2022-01-14 13:06:32.149 AEDT client backend[21853]
pg_regress/publication LOG: !!> ColId OptWhereClause
2022-01-14 13:06:32.149 AEDT client backend[21853]
pg_regress/publication STATEMENT: CREATE PUBLICATION testpub5 FOR
TABLE testpub_rf_tbl1, testpub_rf_tbl2 WHERE (c <> 'test' AND d < 5)
WITH (publish = 'insert');

(for syntax2)
2022-01-14 13:06:32.186 AEDT client backend[21853]
pg_regress/publication LOG: !!> TABLE relation_expr OptWhereClause
2022-01-14 13:06:32.186 AEDT client backend[21853]
pg_regress/publication STATEMENT: CREATE PUBLICATION testpub_syntax2
FOR TABLE testpub_rf_tbl1, testpub_rf_schema1.testpub_rf_tbl5 WHERE (h
< 999) WITH (publish = 'insert');
2022-01-14 13:06:32.186 AEDT client backend[21853]
pg_regress/publication LOG: !!> ColId indirection OptWhereClause
2022-01-14 13:06:32.186 AEDT client backend[21853]
pg_regress/publication STATEMENT: CREATE PUBLICATION testpub_syntax2
FOR TABLE testpub_rf_tbl1, testpub_rf_schema1.testpub_rf_tbl5 WHERE (h
< 999) WITH (publish = 'insert');

From those logs you can see although the SQLs looked to be similar
they actually take different PublicationObjSpec execution paths in the
gram.y: i.e. " ColId OptWhereClause" Versus " ColId indirection
OptWhereClause"

~~

So this review comment can be skipped. Both tests should be retained.

------
Kind Regards,
Peter Smith.
Fujitsu Australia

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tim McNamara 2022-01-17 01:11:59 New developer papercut - Makefile references INSTALL
Previous Message Julien Rouhaud 2022-01-17 00:40:38 Re: drop tablespace failed when location contains .. on win32