Hi Zsolt,
Thanks for the sharp testing. Attached is v12 with a fix for one of your
two cases; the other needs more design work than a small amendment.
Case 2 (outer-type ALTER + reassign), fixed in v12. The false positive came from er_tupdesc_id (set once at ExpandedRecord creation)
being left stale when the record was reassigned in place via expanded_record_set_tuple.
v12 refreshes it at the same two in-place set_tuple sites where I already added the nested-snapshot refresh.
Reassignment with fresh data now returns the row (matching master); reassignment without a follow-up write still errors.
Case 1 (array-carried composite in a scalar PL/pgSQL variable) still open.
Confirmed still crashes on v12. The v11/v12 snapshot lives on PLpgSQL_rec; here the stale bytes flow through arr foo[], which is a
PLpgSQL_var that is outside the current mechanism's scope.
A small point-fix doesn't cover this properly, because the same shape extends to any
composite Datum that predates an ALTER (cursors, function args, temp table rows, etc.).
I'd rather propose a design for this separately, likely a session-scoped set of "types altered in this transaction" plus
a check at composite-read time. Happy to open a fresh thread on it.
Regards,
Surya Poondla
