RE: row filtering for logical replication

On Tues, Nov 23, 2021 2:27 PM vignesh C <vignesh21@gmail.com> wrote:
> On Thu, Nov 18, 2021 at 7:04 AM Peter Smith <smithpb2250@gmail.com>
> wrote:
> >
> > PSA new set of v40* patches.
> 
> Few comments:
> 1) When a table is added to the publication, replica identity is checked. But
> while modifying the publish action to include delete/update, replica identity is
> not checked for the existing tables. I felt it should be checked for the existing
> tables too.

In addition to this, I think we might also need some check to prevent user from
changing the REPLICA IDENTITY index which is used in the filter expression.

I was thinking is it possible do the check related to REPLICA IDENTITY in
function CheckCmdReplicaIdentity() or In GetRelationPublicationActions(). If we
move the REPLICA IDENTITY check to this function, it would be consistent with
the existing behavior about the check related to REPLICA IDENTITY(see the
comments in CheckCmdReplicaIdentity) and seems can cover all the cases
mentioned above.

Another comment about v40-0001 patch:


+            char *relname = pstrdup(RelationGetRelationName(rel));
+
             table_close(rel, ShareUpdateExclusiveLock);
+
+            /* Disallow duplicate tables if there are any with row-filters. */
+            if (t->whereClause || list_member_oid(relids_with_rf, myrelid))
+                ereport(ERROR,
+                        (errcode(ERRCODE_DUPLICATE_OBJECT),
+                         errmsg("conflicting or redundant row-filters for \"%s\"",
+                                relname)));
+            pfree(relname);

Maybe we can do the error check before table_close(), so that we don't need to
invoke pstrdup() and pfree().


Best regards,
Hou zj