Michael Paquier <michael(at)paquier(dot)xyz> writes:
> Any objections about getting 947789f applied to REL_13_STABLE and
> REL_12_STABLE and see this issue completely gone from all the versions
> supported?
No objections to back-patching the fix, but I wonder if we can find
some mechanical way to prevent this sort of error in future. It's
surely far from obvious that we need to apply heap_inplace_update
to a raw tuple rather than a syscache entry.
A partial fix perhaps could be to verify that the supplied tuple
is the same length as what we see on-disk? It's partial because
it'd only trigger if there had actually been a toasted-field
expansion, so it'd most likely not catch such coding errors
during developer testing.
regards, tom lane