RE: Logical replication row filter loses unchanged toasted columns

On Monday, August 17, 2026 8:15 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.
> To me, that looks like a clear inversion of responsibilities. I don't think LR
> should push its hard problems to a user or workload that might be unable to
> fix the relevant issues. If the logical replication framework can't handle some
> configurations, it should error out, the DDL handler should be adapted so that
> it can't be configured in that way, or the framework should adapted to be able
> to handle the configuration, but in no case should Logical Replication push its
> limitations onto non-REPLICATION users that are just using the table like any
> other normal table.

The problem is that adding these checks in CREATE/ALTER PUBLICATION alone won't
catch all illegal cases.

Consider the existing rule: UPDATE and DELETE can only be published when a
replica identity exists. Even if we add checks in publication DDLs to error out
when replica identity is not specified and UPDATE is published, there are many
other DDLs unrelated to logical replication that could bypass the checks. The
most obvious ones are ALTER TABLE ... REPLICA IDENTITY and DROP INDEX, which can
remove the replica identity. Other DDLs like CREATE TABLE or ATTACH PARTITION
are also risky, because newly added or attached tables may be automatically
published due to FOR ALL TABLES publication settings. There could be even more
affected DDLs that we haven't noticed yet. So, catching it in DDL would also
affect the users that is not executing replication related commands.

Developers tend to add DML checks for all such restrictions - similar to the
replica identity existence check I mentioned above. Another example is the DML
check ensuring that row filter columns are also part of the replica identity. I
think one reason for this pattern is to avoid the maintenance burden of tracking
every risky DDL, both existing and future, and adding checks for each one
individually.

Best Regards,
Zhijie Hou