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 |
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 |