From: | Peter Smith <smithpb2250(at)gmail(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | "houzj(dot)fnst(at)fujitsu(dot)com" <houzj(dot)fnst(at)fujitsu(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, "tanghy(dot)fnst(at)fujitsu(dot)com" <tanghy(dot)fnst(at)fujitsu(dot)com>, Euler Taveira <euler(at)eulerto(dot)com>, Greg Nancarrow <gregn4422(at)gmail(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>, Ajin Cherian <itsajin(at)gmail(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(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-12 07:18:09 |
Message-ID: | CAHut+PstfayE8eA2ue8N9gC2Fig=mDDjiGR=NdCw8yeTq2f+Lg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Here are some review comments for v62-0002
~~~
1. src/backend/replication/pgoutput/pgoutput.c -
pgoutput_row_filter_update_check
+ * If the change is to be replicated this function returns true, else false.
+ *
+ * Examples: Let's say the old tuple satisfies the row filter but the new tuple
+ * doesn't. Since the old tuple satisfies, the initial table synchronization
+ * copied this row (or another method was used to guarantee that there is data
+ * consistency). However, after the UPDATE the new tuple doesn't satisfy the
The word "Examples:" should be on a line by itself; not merged with
the 1st example "Let's say...".
~~~
2. src/backend/replication/pgoutput/pgoutput.c -
pgoutput_row_filter_update_check
+ /*
+ * For updates, both the new tuple and old tuple needs to be checked
+ * against the row filter. The new tuple might not have all the replica
+ * identity columns, in which case it needs to be copied over from the old
+ * tuple.
+ */
Typo: "needs to be checked" --> "need to be checked"
~~~
3. src/backend/replication/pgoutput/pgoutput.c - pgoutput_row_filter_init
Missing blank line before a couple of block comments, here:
bool pub_no_filter = false;
List *schemarelids = NIL;
/*
* If the publication is FOR ALL TABLES then it is treated the
* same as if this table has no row filters (even if for other
* publications it does).
*/
if (pub->alltables)
pub_no_filter = true;
/*
* If the publication is FOR ALL TABLES IN SCHEMA and it overlaps
* with the current relation in the same schema then this is also
* treated same as if this table has no row filters (even if for
* other publications it does).
*/
else
~~~
4. src/backend/replication/pgoutput/pgoutput.c - pgoutput_row_filter_init
This function was refactored out of the code from pgoutput_row_filter
in the v62-0001 patch. So probably there are multiple comments from my
earlier v62-0001 review [1] of that pgoutput_row_filter function, that
now also apply to this pgoutput_row_filter_init function.
~~~
5. src/tools/pgindent/typedefs.list - ReorderBufferChangeType
Actually, the typedef for ReorderBufferChangeType was added in the
62-0001, so this typedef change should've been done in patch 0001 and
it can be removed from patch 0002
Kind Regards,
Peter Smith.
Fujitsu Australia
From | Date | Subject | |
---|---|---|---|
Next Message | Julien Rouhaud | 2022-01-12 07:18:16 | Re: Asynchronous and "direct" IO support for PostgreSQL. |
Previous Message | Julien Rouhaud | 2022-01-12 07:01:40 | Re: cfbot wrangling (was Re: Add checkpoint and redo LSN to LogCheckpointEnd log message) |