Horton

Re: row filtering for logical replication

Amit Kapila <amit.kapila16@gmail.com>

View thread
From: Amit Kapila <amit.kapila16@gmail.com>
To: "tanghy.fnst@fujitsu.com" <tanghy.fnst@fujitsu.com>
Cc: "houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.com>, Peter Smith <smithpb2250@gmail.com>, Euler Taveira <euler@eulerto.com>, Greg Nancarrow <gregn4422@gmail.com>, vignesh C <vignesh21@gmail.com>, Ajin Cherian <itsajin@gmail.com>, Dilip Kumar <dilipbalaut@gmail.com>, Rahila Syed <rahilasyed90@gmail.com>, Peter Eisentraut <peter.eisentraut@enterprisedb.com>, Önder Kalacı <onderkalaci@gmail.com>, japin <japinli@hotmail.com>, Michael Paquier <michael@paquier.xyz>, David Steele <david@pgmasters.net>, Craig Ringer <craig@2ndquadrant.com>, Amit Langote <amitlangote09@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2022-01-11T09:48:19Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Release cache tuple when no longer needed

  2. Add some additional tests for row filters in logical replication.

  3. Fix one of the tests introduced in commit 52e4f0cd47.

  4. Allow specifying row filters for logical replication of tables.

  5. Move scanint8() to numutils.c

  6. Replace Test::More plans with done_testing

  7. Reduce relcache access in WAL sender streaming logical changes

  8. Small cleanups related to PUBLICATION framework code

  9. Add a view to show the stats of subscription workers.

  10. Allow publishing the tables of schema.

  11. Doc: improve documentation of CREATE/ALTER SUBSCRIPTION.

  12. Add PublicationTable and PublicationRelInfo structs

  13. Remove unused argument "txn" in maybe_send_schema().

  14. Add prepare API support for streaming transactions in logical replication.

  15. Unify PostgresNode's new() and get_new_node() methods

  16. Use l*_node() family of functions where appropriate

  17. Add support for prepared transactions to built-in logical replication.

  18. Restore the portal-level snapshot after procedure COMMIT/ROLLBACK.

  19. Rename a parse node to be more general

  20. Remove unused column atttypmod from initial tablesync query

  21. SEARCH and CYCLE clauses

On Tue, Jan 11, 2022 at 1:32 PM tanghy.fnst@fujitsu.com
<tanghy.fnst@fujitsu.com> wrote:
>
> On Tuesday, January 11, 2022 10:16 AM houzj.fnst@fujitsu.com <houzj.fnst@fujitsu.com> wrote:
> >
> > Attach the v62 patch set which address the above comments and slightly
> > adjust the commit message in 0002 patch.
> >
>
> I saw a possible problem about Row-Filter tablesync SQL, which is related
> to partition table.
>
> If a parent table is published with publish_via_partition_root off, its child
> table should be taken as no row filter when combining the row filters with OR.
> But when using the current SQL, this publication is ignored.
>
> For example:
> create table parent (a int) partition by range (a);
> create table child partition of parent default;
> create publication puba for table parent with (publish_via_partition_root=false);
> create publication pubb for table child where(a>10);
>
> Using current SQL in patch:
> (table child oid is 16387)
> SELECT DISTINCT pg_get_expr(prqual, prrelid) FROM pg_publication p
> INNER JOIN pg_publication_rel pr ON (p.oid = pr.prpubid)
> WHERE pr.prrelid = 16387 AND p.pubname IN ( 'puba', 'pubb' )
> AND NOT (select bool_or(puballtables)
> FROM pg_publication
> WHERE pubname in ( 'puba', 'pubb' ))
> AND NOT EXISTS (SELECT 1
> FROM pg_publication_namespace pn, pg_class c, pg_publication p
> WHERE c.oid = 16387 AND c.relnamespace = pn.pnnspid AND p.oid = pn.pnpubid AND p.pubname IN ( 'puba', 'pubb' ));
> pg_get_expr
> -------------
>  (a > 10)
> (1 row)
>
>
> I think there should be no filter in this case, because "puba" publish table child
> without row filter. Thoughts?
>

I also think so.

> To fix this problem, we could use pg_get_publication_tables function in
> tablesync SQL to filter which publications the table belongs to. How about the
> following SQL, it would return NULL for "puba".
>
> SELECT DISTINCT pg_get_expr(pr.prqual, pr.prrelid)
> FROM pg_publication p
> LEFT OUTER JOIN pg_publication_rel pr
>     ON (p.oid = pr.prpubid AND pr.prrelid = 16387),
> LATERAL pg_get_publication_tables(p.pubname) GPT
> WHERE GPT.relid = 16387 AND p.pubname IN ( 'puba', 'pubb' );
>  pg_get_expr
> -------------
>  (a > 10)
>
> (2 rows)
>

One advantage of this query is that it seems to have simplified the
original query by removing NOT conditions. I haven't tested this yet
but logically it appears correct to me.

-- 
With Regards,
Amit Kapila.