Request a Demo
Home   >   mailing lists

Re: BUG #19382: Server crash at __nss_database_lookup - Mailing list pgsql-bugs

From surya poondla
Subject Re: BUG #19382: Server crash at __nss_database_lookup
Date
Msg-id CAOVWO5oRGPd7mA3d85jNYmjLNfeBAca5oDcHTfRFxbAwPLxs5g@mail.gmail.com
Whole thread Raw
In response to Re: BUG #19382: Server crash at __nss_database_lookup  (Andrey Borodin <x4mmm@yandex-team.ru>)
List pgsql-bugs
Tree view
Hi All,

Thanks for the review Andrey.

On Thu, Apr 2, 2026 at 4:18 AM Andrey Borodin <x4mmm@yandex-team.ru> wrote:
Hi!

Thanks for working on this!

> On 20 Mar 2026, at 23:16, surya poondla <suryapoondla4@gmail.com> wrote:
>
> I'll post an updated patch with this improvement.

After your patch Postgres still crashes on this test:

CREATE TYPE foo AS (a INT, b INT);
BEGIN;
DECLARE c CURSOR FOR SELECT (i, power(2, 30))::foo FROM generate_series(1,10) i;
FETCH c;
ALTER TYPE foo ALTER ATTRIBUTE b TYPE TEXT;
FETCH c;
COMMIT;

This test case was proposed in this thread, but I suggest treating this as a separate bug needing separate fix.

Thank you for reporting this. Yes the cursor case can be treated as a separate bug.
Though the 2 crash scenarios have the same root cause (record_out() interpreting old data with new type definition) they require different fix requirements.
1. PL/pgSQL case (this patch): ExpandedRecords already carry er_tupdesc_id the version tracking infrastructure exists. The fix detects the mismatch and converts the data. This is a self-contained bug fix using existing mechanisms.
2. Cursor case: Flat HeapTuples carry no type version information, they only have the type OID, which doesn't change after ALTER TYPE. Fixing this requires adding new infrastructure that PostgreSQL doesn't have today (e.g., storing tupDesc_identifier in Portal structures, or adding version fields to HeapTupleHeaders). This is a broader architectural change that affects core structures like PortalData, pquery.c, and potentially portalmem.c. We need to see how to add version tracking to composite-type values. I will work on this fix in parallel.

 
In my opinion in both cases (PL/pgSQL + CURSOR) we should error out instead of trying to remediate type changes.

I've simplified the fix. Instead of converting the record data, we now raise a clear error when a composite type is altered mid-transaction after the record was populated.
This also addresses the performance concern raised earlier since there's no conversion logic at all now.                                                                                                                                                  
                                                           
Updated patch attached.
 
Regards,
Surya Poondla
Attachment

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #19449: Massive performance degradation for complex query on Postgres 16+ (few seconds -> multiple hours)