Re: BUG #19382: Server crash at __nss_database_lookup

From: surya poondla <suryapoondla4(at)gmail(dot)com>
To: songjinzhou <tsinghualucky912(at)foxmail(dot)com>
Cc: dllggyx <dllggyx(at)outlook(dot)com>, pgsql-bugs <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: BUG #19382: Server crash at __nss_database_lookup
Date: 2026-03-20 18:16:16
Message-ID: CAOVWO5oH37CETZuxxXw3dhCMOHPMA0xFoJBWTpfJ06OV7sGzTQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Hi Songjinzhou,

Thank you for reviewing the patch.

You're correct that there is a minor inefficiency, once a
tupDesc_identifier version mismatch is detected, the patch allocates
new_values/new_nulls arrays and calls deconstruct_expanded_record() before
knowing whether any field types actually differ.
If the version changed but no field types changed (e.g., a constraint-only
ALTER), we do unnecessary work and hit the if (!need_conversion) return
late.

That said, your suggestion is clean and correct. I can restructure the code
to do a first pass over the TupleDesc attributes (which is pure metadata,
no deconstruction needed) to set need_conversion,
and only proceed with deconstruct_expanded_record() and array allocation if
that returns true. This avoids any unnecessary memory allocation in that
intermediate case.

I'll post an updated patch with this improvement.

Thanks again for the careful review!

Regards,
Surya Poondla

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2026-03-20 20:26:13 Re: BUG #19435: Error: "No relation entry for relid 2" Triggered by Complex Join with Self-Referencing Tables
Previous Message surya poondla 2026-03-20 18:01:22 Re: Two issues with REFRESH MATERIALIZED VIEW CONCURRENTLY