Re: BUG #19382: Server crash at __nss_database_lookup

From: Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>
To: surya poondla <suryapoondla4(at)gmail(dot)com>
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org, songjinzhou <tsinghualucky912(at)foxmail(dot)com>
Subject: Re: BUG #19382: Server crash at __nss_database_lookup
Date: 2026-07-13 22:18:35
Message-ID: CAN4CZFOGb_BtkpmoHTuJao3Ob0KcC1=kQ3DTgwOAoOzMAHE83g@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Hello!

The crash is still reproducible if an old type value is carried in an
array variable and then gets re-assigned:

create type foo as (a int, b int);
create function p1() returns foo as $$
declare arr foo[]; r foo;
begin
arr := array[row(123, power(2,30)::int4)::foo];
alter type foo alter attribute b type text;
r := arr[1];
return r;
end $$ language plpgsql;
select p1();

Or it crashes the same way if we return arr[1] directly, or if we
assign it to a field of another composite type.

And I also found another false positive:

create type foo3 as (a int, b int);
create function p3() returns foo3 as $$
declare r foo3;
begin
r := row(1, 2)::foo3;
alter type foo3 alter attribute b type text;
r := row(1, 'hello')::foo3;
return r;
end $$ language plpgsql;
select p3();

In response to

Browse pgsql-bugs by date

  From Date Subject
Previous Message surya poondla 2026-07-13 20:53:55 Re: BUG #19382: Server crash at __nss_database_lookup