On Wed, Sep 2, 2026 at 11:40 AM vignesh C <[email protected]> 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.
