| 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: | Whole Thread | Raw Message | 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 |