crash in pg_identify_object_as_address

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

Responses

Browse pgsql-hackers by date

  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