Re: BUG #19382: Server crash at __nss_database_lookup

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