On Mon, Aug 17, 2026 at 5:45 PM Matthias van de Meent <[email protected]> wrote: > > I don't understand the position of the LR developers here. > > AFAIK, Logical Replication is (and has been) positioned as a > transparent add-on feature, that adds a new feature (replicating the > logical changes in a database) without removing functionality (such as > DML). LR's lack of support for certain functionalities (such as DDL, > or until recently sequences) didn't remove those functionalities from > the table or database that was configured for DDL, but instead the > feature was built in a way that replication couldn't be set up for > some features (sequences), or the replication stream would move into > an error state (most breaking DDL changes). > > The solution that the developers seem to lean towards here is exactly > opposite to this: Enabling logical replication on a table breaks [^1] > (or would break [^2]) existing DML workloads. >
The reason for existing behavior is that users can add/change RI after creating publications, so we can't simply reject creating publications when a proper RI is not defined on the table yet. Another related example is that CREATE PUBLICATION p FOR TABLE t WHERE (non_ri_col > 5) succeeds today even if t's RI doesn't cover non_ri_col but will give error at UPDATE/DELETE time. So, we are trying to follow the similar pattern here. > > [^1] tables without replication identity can recieve neither UPDATEs > nor DELETEs if those commands are included in the publication. > [^2] the general direction of this thread seems to lean towards > blocking DML on affected tables. -- With Regards, Amit Kapila.
