AssertArg failure in src/backend/executor/functions.c:check_sql_fn_retval()

From: Piotr Stefaniak <postgres(at)piotr-stefaniak(dot)me>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: AssertArg failure in src/backend/executor/functions.c:check_sql_fn_retval()
Date: 2016-03-27 00:14:01
Message-ID: BLU436-SMTP2323AD85BEB9376E68788A2F2850@phx.gbl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 Content-Type Size
check_sql_fn_retval-IsPolymorphicType-trace.txt text/plain 3.7 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Janes 2016-03-27 03:45:03 Re: Draft release notes for next week's releases
Previous Message Tom Lane 2016-03-27 00:01:59 Re: Fix for OpenSSL error queue bug