Hi Zhijie,

>
> I feel catching such an unchanged toasted column issue during INSERT in the
> apply worker could be better. The apply worker provides native context
> about the
> transaction and the action being replayed, making the error easier to
> diagnose.
> Erroring in the apply worker also gives users more flexibility to resolve
> the
> issue,


This is what I was arriving at myself as well.  FWIW, here is a patch
that does precisely that along with test case changes.

I think this should go in now, so that a change which cannot be applied
completely stops being silently turned into a NULL on the subscriber.
For the same reason I think it should be back-patched to 15, which is
where row filters were added and so is the first affected branch.

Any option along the lines of the option B that Shinya-san outlined
changes what the publisher writes to WAL, so for master it will need a
commitfest cycle regardless.  I would rather not have the silent data
loss wait for that.

Thanks,
Nikhil
---
Nikhil Sontakke
PlanetScale

Attachment: 0001-Refuse-a-logical-replication-INSERT-that-is-m-master.patch
Description: Binary data

Reply via email to