From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | crash in pg_identify_object_as_address |
Date: | 2019-02-18 20:27:43 |
Message-ID: | 20190218202743.GA12392@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello
I just came across a crash while debugging some corrupted system
catalogs; pg_identify_object_as_address fails to cope with some NULL
input, causing a crash. Attached patch fixes it. Naturally, the output
array will contain NULL members in the output, but that's better than
crashing ...
(The first hunk is purely speculative; I haven't seen anything that
requires that. The actual fix is in the other hunks. But seems better
to be defensive.)
The crash can be reproduced thusly
create function f() returns int language plpgsql as $$ begin return 1; end; $$;
update pg_proc set pronamespace = 9999 where proname = 'f' returning oid \gset
select * from pg_identify_object_as_address('pg_proc'::regclass, :oid, 0);
After the patch, the last line returns:
type | object_names | object_args
----------+--------------+-------------
function | {NULL,f} | {}
where the NULL obviously corresponds to the bogus pg_namespace OID being
referenced.
The patch is on 9.6. I checked 10 and it applies fine there. My
intention is to apply to all branches since 9.5.
--
Álvaro Herrera PostgreSQL Expert, https://www.2ndQuadrant.com/
Attachment | Content-Type | Size |
---|---|---|
pg_identify_object_as_address-crash.patch | text/x-diff | 1.5 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2019-02-18 21:53:11 | Re: Proving IS NOT NULL inference for ScalarArrayOpExpr's |
Previous Message | Andres Freund | 2019-02-18 20:25:11 | Re: unconstify equivalent for volatile |