Re: BUG #19382: Server crash at __nss_database_lookup

Hi Zsolt,

Thanks for testing. I reproduced both with v13 applied to master as of
Nov 6 (0607aa61090), they are two separate bugs in the patch:

1) foreign_key: the patch treats any change of the type cache's
tupDesc_identifier as an ALTER TYPE, but typcache assigns a new
identifier every time it reloads a type's tuple descriptor, even when
nothing changed. The fk_self_ref test added in e5f6a7a28c4 runs
GRANT/REVOKE inside a BEFORE DELETE trigger, so the following
RETURN OLD fails with a spurious "was altered" error. Outside the
tests, a GRANT on a table (even from another session) while a
function holds a row of it in a variable can hit the same thing.

2) The segfault: collect_composite_type_versions() walks
typentry->tupDesc without pinning it, and the catalog lookups inside
that loop can free it, which under debug_discard_caches happens
almost every time.

However, I don't plan to fix either. The CVE-2026-6460 commits from
Andres and Heikki (e.g. 245eb832f88), committed on 2026-11-09 and
back-patched to 14, now catch these when the row is deformed. I re-ran
all 12 crash reproducers posted in this thread, including Kirill's
ALTER TABLE variant, the cursor case, and your array-carried cases,
which v13 didn't cover. On master from just before that series
(0607aa61090) all 12 crash; on current master, without this patch, all
12 raise "row type of datum tuple was altered after the datum's
creation" instead.

Your p3 example (reassigning fresh data after the ALTER) now errors on
master too, with "using outdated tuple descriptor when deforming row type";
commit 245eb832f88 switched plpgsql_record's expected output for the
same pattern from success to that error.

So I'm withdrawing this patch and will mark CF 6449 accordingly.
Thanks to you, Kirill, Andrey, and songjinzhou for the reviews and testing.

Regards,
Surya Poondla