Re: Logical replication row filter loses unchanged toasted columns

On Wed, Sep 2, 2026 at 11:40 AM vignesh C <vignesh21(at)gmail(dot)com> wrote:
>
> Following up on the concurrent 'ALTER PUBLICATION' problem I reported
> yesterday: the race window itself is not specific to this patch. It
> also exists on HEAD through a different scenario of the same stale
> relcache state, and I think that issue can be fixed separately.
>
> The relevant invariant is that a publication row filter may only
> reference replica identity columns. This is not checked when the
> filter is created — 'ALTER PUBLICATION' accepts a filter on any column
> — but it is checked at DML time from the publication descriptor:
> ...
> RelationBuildPublicationDesc(rel, &pubdesc);
> if (cmd == CMD_UPDATE && !pubdesc.rf_valid_for_update)
> ereport(ERROR,
> errmsg("cannot update table \"%s\"", ...),
> errdetail("Column used in the publication WHERE expression "
> "is not part of the replica identity."));
> ...
>
> Since 'ALTER PUBLICATION ... ADD TABLE' takes only
> 'ShareUpdateExclusiveLock', a filter on a non-replica-identity column
> can be committed after 'CheckCmdReplicaIdentity()' has already allowed
> the UPDATE.
>
> I can reproduce this with the same injection point as before, without
> any TOAST data:
> CREATE TABLE t (id int PRIMARY KEY, val int);
> CREATE PUBLICATION pub_sync FOR TABLE t;
> CREATE PUBLICATION pub_filtered;
> -- Subscribe to both, then:
> INSERT INTO t VALUES (1, 1);
> ALTER PUBLICATION pub_sync DROP TABLE t;
>
> -- Session A:
> SELECT injection_points_set_local();
> SELECT injection_points_attach('heap_update-before-pin', 'wait');
> UPDATE t SET val = 2 WHERE id = 1;
>
> -- Session B, while Session A is waiting:
> ALTER PUBLICATION pub_filtered ADD TABLE t WHERE (val = 1);
>
> -- Wake Session A:
> SELECT injection_points_wakeup('heap_update-before-pin');
>
> I have attached 'row_filter_nonri_column_race.pl', which reproduces the issue.
> I feel the issue reported at [1] is independent of the patch under
> review and should be addressed separately, along with this issue, in a
> separate thread.
>

Agreed. Let's start a separate thread for this case.

--
With Regards,
Amit Kapila.