Re: Logical replication row filter loses unchanged toasted columns

On Mon, Aug 17, 2026 at 5:45 PM Matthias van de Meent
<boekewurm+postgres(at)gmail(dot)com> 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.