RE: Logical replication row filter loses unchanged toasted columns

Dear Kato-san,

> I found a bug in the row filter's UPDATE to INSERT transformation. An
> unchanged column that is stored out-of-line silently becomes NULL on
> the subscriber, unless it is part of the replica identity.

I could also reproduce the failure with your reproducer.

> ALTER TABLE t ALTER COLUMN body SET STORAGE EXTERNAL;
> CREATE PUBLICATION p FOR TABLE t WHERE (id = 7);
> INSERT INTO t VALUES (3, repeat('a', 5000));

Note that I could reproduce without setting the storage parameter to EXTERNAL.
E.g., we can put string which has lower compression rate, like below.

```
CREATE EXTENSION pgcrypto;
INSERT INTO t SELECT 3, string_agg(encode(gen_random_bytes(1000), 'hex'), '') FROM generate_series(1, 5);
```

> We cannot simply fill the value in. As Petr put it when
> LOGICALREP_COLUMN_UNCHANGED was being discussed [1], such values "are
> not written to WAL nor accessible via historic snapshot", so the
> output plugin never sees them.

The historic snapshot seems to aim reading old version of catalogs, but toasted tables
are not.

> I see three ways to deal with this.

Option B would have performance regressions not only for logical replication but
also for normal workloads. We need to generate for narrower cases, e.g., check
the filtering rule and generate WAL for unchanged toasted columns, if we want to
choose this. I'm not sure it's possible or how engineering would be needed though.

So, I prefer to 1) implement option A for all branches first, and 2) investigate
option B separately. Regarding the C, it can be chosen if the option A needs lots
of codes.

> The only way forward is
> pg_replication_slot_advance() or recreating the subscription.

Can we also use ALTER SUBSCRIPTION SKIP?

Best regards,
Hayato Kuroda
FUJITSU LIMITED