RE: row filtering for logical replication

On Mon, Dec 27, 2021 9:16 PM houzj(dot)fnst(at)fujitsu(dot)com <houzj(dot)fnst(at)fujitsu(dot)com> wrote:
>
> On Thur, Dec 23, 2021 4:28 PM Peter Smith <smithpb2250(at)gmail(dot)com> wrote:
> > Here is the v54* patch set:
>
> Attach the v55 patch set which add the following testcases in 0003 patch.
> 1. Added a test to cover the case where TOASTed values are not included in the
> new tuple. Suggested by Euler[1].
>
> Note: this test is temporarily commented because it would fail without
> applying another bug fix patch in another thread[2] which log the detoasted
> value in old value. I have verified locally that the test pass after
> applying the bug fix patch[2].
>
> 2. Add a test to cover the case that transform the UPDATE into INSERT. Provided
> by Tang.
>

Thanks for updating the patches.

A few comments:

1) v55-0001

-/*
- * Gets the relations based on the publication partition option for a specified
- * relation.
- */
List *
GetPubPartitionOptionRelations(List *result, PublicationPartOpt pub_partopt,
Oid relid)

Do we need this change?

2) v55-0002
* Multiple ExprState entries might be used if there are multiple
* publications for a single table. Different publication actions don't
* allow multiple expressions to always be combined into one, so there is
- * one ExprSTate per publication action. Only 3 publication actions are
+ * one ExprState per publication action. Only 3 publication actions are
* used for row filtering ("insert", "update", "delete"). The exprstate
* array is indexed by ReorderBufferChangeType.
*/

I think this change can be merged into 0001 patch.

3) v55-0002
+static bool pgoutput_row_filter_update_check(enum ReorderBufferChangeType changetype, Relation relation,
+ HeapTuple oldtuple, HeapTuple newtuple,
+ RelationSyncEntry *entry, ReorderBufferChangeType *action);

Do we need parameter changetype here? I think it could only be
REORDER_BUFFER_CHANGE_UPDATE.

Regards,
Tang