Re: BUG #18840: Segmentation fault in executing select unnest(array(oidvector))

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: ylshiyu@126.com
Cc: pgsql-bugs@lists.postgresql.org
Date: 2025-03-12T23:37:33Z
Lists: pgsql-bugs

Attachments

PG Bug reporting form <noreply@postgresql.org> writes:
> I encountered a segmentation fault when using 'select
> unnest(array(oidvector))'.

Thanks for the report!  The cause of this bug is confusion about
whether oidvector is an array type or scalar type.  It is an array
type, because get_element_type says that its element type is "oid",
but it is also a scalar type, because get_array_type says that its
array type is "oidvector[]".  The parser and planner think that the
result of the ARRAY() construct should be of type oidvector[], but
arrayfuncs.c's initArrayResultAny() comes to the opposite conclusion.

Before initArrayResultAny() was invented in 9.5, we correctly executed
the construct and produced oidvector[].  So I'm inclined to think that
that's the right answer, and 0001 attached makes it that way again.

While poking at this I found a related problem, which is that
ARRAY[oidvector] also thinks the result type is oidvector.  This seems
wrong to me, because there's not supposed to be any such thing as a
multidimensional oidvector.  I couldn't find any case that crashed as
a result, but I may just not have tried hard enough.  It's certainly
possible to exhibit clearly-wrong results, for example

regression=# select array['11 22 33'::int2vector];
 array 
-------
 1
(1 row)

0002 attached fixes that part.

The crash you found is sufficient reason to back-patch 0001, even
though it changes results in some non-crash cases.  I'm less sure
about whether to back-patch 0002.  If anyone can find a crash
case involving ARRAY[], I think we should do so.

			regards, tom lane

Commits

  1. Fix ARRAY_SUBLINK and ARRAY[] for int2vector and oidvector input.