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.
