AssertArg failure in src/backend/executor/functions.c:check_sql_fn_retval() - Mailing list pgsql-hackers

From Piotr Stefaniak
Subject AssertArg failure in src/backend/executor/functions.c:check_sql_fn_retval()
Date
Msg-id BLU436-SMTP2323AD85BEB9376E68788A2F2850@phx.gbl
Whole thread Raw
Responses Re: AssertArg failure in src/backend/executor/functions.c:check_sql_fn_retval()
List pgsql-hackers
Hi,

using sqlsmith I found a way to induce an AssertArg failure in
src/backend/executor/functions.c:check_sql_fn_retval() for
assert-enabled builds. It boils down to creating a function and calling
it like this:

CREATE FUNCTION bad_argument_assert(anyarray, integer) RETURNS anyarray
LANGUAGE sql AS $$select $1$$;
SELECT bad_argument_assert(CAST(NULL AS ANYARRAY), 0);

TRAP: BadArgument("!(!((rettype) == 2283 || (rettype) == 2277 ||
(rettype) == 2776 || (rettype) == 3500 || (rettype) == 3831))", File:
"src/backend/executor/functions.c", Line: 1539)

Back-trace attached.

I've done a little bit of git-bisecting and this potential failure is
there since at least February 2012.

The comment above the function definition specifically says that "we
should never see a polymorphic pseudotype such as ANYELEMENT as rettype"
but given that a non-assert-enabled build seems to cope with such
pseudotypes well, I'm unsure the AssertArg is needed there at all.

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Fix for OpenSSL error queue bug
Next
From: Jeff Janes
Date:
Subject: Re: Draft release notes for next week's releases