BUG #18840: Segmentation fault in executing select unnest(array(oidvector))
The following bug has been logged on the website:
Bug reference: 18840
Logged by: yang lei
Email address: ylshiyu@126.com
PostgreSQL version: 16.8
Operating system: Ubuntu 22.04
Description:
Hi,
I encountered a segmentation fault when using 'select
unnest(array(oidvector))'.
bug demo:
CREATE TABLE my_table (
id SERIAL PRIMARY KEY,
oidvector_col oidvector
);
INSERT INTO my_table (oidvector_col) VALUES ('12345 67890 54321');
SELECT unnest(ARRAY(SELECT oidvector_col)) from my_table;
server closed the connection unexpectedly
This
probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: 2025-03-12
20:18:04.642 CST [1478] LOG: server process (PID 1578) was terminated by
signal 11: Segmentation fault
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
Attachments:
v1-0001-Fix-initArrayResultAny-for-int2vector-and-oidvect.patchtext/x-diff; charset=us-ascii; name*0=v1-0001-Fix-initArrayResultAny-for-int2vector-and-oidvect.p; name*1=atchDownload+163-6
v1-0002-Make-ARRAY-treat-int2vector-and-oidvector-like-AR.patchtext/x-diff; charset=us-ascii; name*0=v1-0002-Make-ARRAY-treat-int2vector-and-oidvector-like-AR.p; name*1=atchDownload+39-31
I wrote:
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.
After sleeping on it I concluded that both changes should be
back-patched: if anyone were depending on ARRAY[] over int2vector
or oidvector, you'd think they'd have noticed and reported the
broken cases by now. Hence, pushed as one patch.
regards, tom lane