Re: Logical replication row filter loses unchanged toasted columns

On Wed, 12 Aug 2026 at 05:23, Shinya Kato <shinya11(dot)kato(at)gmail(dot)com> wrote:
>
> I see three ways to deal with this.
>
> Option A: detect the missing value in pgoutput_row_filter() and raise
> an error naming the table and the column, trading silent data loss for
> a loud failure. [...]
>
> Option B: when a table belongs to a publication with a row filter,
> make heap_update() log the whole old tuple, as it already does for
> REPLICA IDENTITY FULL. [...]
>
> Option C: document the restriction and leave the behavior alone. [...]

Or, an option D: Forbid the creation (and use) of filtered publication
table definitions for tables which contain a non-identity
varlena-typed column (i.e. the type's typlen is -1).

Publishing varlena identity columns is safe, and users can just avoid
including varlena columns when they add a filter; we should not allow
users to create publications of which we know ahead of time that the
data stream is likely to break on our side.

I think this option D can be backported, but would require some
pg_upgrade checks.

Kind regards,

Matthias van de Meent
Databricks (https://www.databricks.com)