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

From Zsolt Parragi
Subject Re: BUG #19382: Server crash at __nss_database_lookup
Date
Msg-id CAN4CZFOGb_BtkpmoHTuJao3Ob0KcC1=kQ3DTgwOAoOzMAHE83g@mail.gmail.com
Whole thread
Responses Re: BUG #19382: Server crash at __nss_database_lookup
List 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();



pgsql-bugs by date:

Previous
From: Nazir Bilal Yavuz
Date:
Subject: Re: BUG #19551: TRAP: failed Assert("max_pinned_buffers > 0")
Next
From: Kenny Chen
Date:
Subject: Re: BUG #19547: libpqrcv_create_slot dereferences NULL on a malformed CREATE_REPLICATION_SLOT reply