Re: array_agg(DISTINCT) caused a segmentation fault - Mailing list pgsql-bugs
From | Alexander Lakhin |
---|---|
Subject | Re: array_agg(DISTINCT) caused a segmentation fault |
Date | |
Msg-id | 4103db46-d888-6d1d-e88d-87c21ed99472@gmail.com Whole thread Raw |
In response to | Re: array_agg(DISTINCT) caused a segmentation fault (David Rowley <dgrowleyml@gmail.com>) |
Responses |
Re: array_agg(DISTINCT) caused a segmentation fault
(David Rowley <dgrowleyml@gmail.com>)
|
List | pgsql-bugs |
Hello David,
13.02.2023 10:44, David Rowley wrote:
13.02.2023 10:44, David Rowley wrote:
I've encountered an issue that could have the same title but it still reproduced after the fix.On Mon, 13 Feb 2023 at 18:29, Fujii Masao <masao.fujii@oss.nttdata.com> wrote:=# SELECT array_agg(distinct val) FROM (SELECT NULL AS val FROM generate_series(1, 2)) hoge; LOG: server process (PID 76507) was terminated by signal 11: Segmentation fault: 11 DETAIL: Failed process was running: SELECT array_agg(distinct val) FROM (SELECT NULL AS val FROM generate_series(1, 2)) hoge;I've now pushed a fix for it and included your test. To get it to crash it needed to be a byref aggregate without a strict transition function. There are not too many of those, which is probably why nobody noticed this before.
The following query:
SELECT array_agg(DISTINCT a ORDER BY a DESC)
FROM (VALUES (1),(1.0),(NULL)) v(a);
Invokes valgrind-detected error:
==00:00:00:03.708 2686358== Invalid read of size 4
==00:00:00:03.708 2686358== at 0x76C4AE: GetMemoryChunkMethodID (mcxt.c:195)
==00:00:00:03.708 2686358== by 0x76C4AE: pfree (mcxt.c:1439)
==00:00:00:03.708 2686358== by 0x3FD547: ExecEvalPreOrderedDistinctSingle (execExprInterp.c:4258)
==00:00:00:03.708 2686358== by 0x3FF203: ExecInterpExpr (execExprInterp.c:1772)
==00:00:00:03.708 2686358== by 0x418792: ExecEvalExprSwitchContext (executor.h:344)
==00:00:00:03.708 2686358== by 0x418792: advance_aggregates (nodeAgg.c:823)
==00:00:00:03.708 2686358== by 0x41A12A: agg_retrieve_direct (nodeAgg.c:2446)
==00:00:00:03.708 2686358== by 0x41A294: ExecAgg (nodeAgg.c:2171)
==00:00:00:03.708 2686358== by 0x40AD3F: ExecProcNodeFirst (execProcnode.c:464)
==00:00:00:03.708 2686358== by 0x40337F: ExecProcNode (executor.h:262)
==00:00:00:03.708 2686358== by 0x40337F: ExecutePlan (execMain.c:1633)
==00:00:00:03.708 2686358== by 0x403542: standard_ExecutorRun (execMain.c:364)
==00:00:00:03.708 2686358== by 0x40360E: ExecutorRun (execMain.c:308)
==00:00:00:03.708 2686358== by 0x5EB971: PortalRunSelect (pquery.c:924)
==00:00:00:03.708 2686358== by 0x5ED31B: PortalRun (pquery.c:768)
==00:00:00:03.708 2686358== Address 0xfffffffffffffff8 is not stack'd, malloc'd or (recently) free'd
==00:00:00:03.708 2686358==
...
==00:00:00:03.708 2686358==
==00:00:00:03.708 2686358== Exit program on first error (--exit-on-first-error=yes)
2023-02-13 10:26:39.276 MSK [2686332] LOG: server process (PID 2686358) exited with exit code 1
2023-02-13 10:26:39.276 MSK [2686332] DETAIL: Failed process was running: SELECT array_agg(DISTINCT a ORDER BY a DESC)
FROM (VALUES (1),(1.0),(NULL)) v(a);
(Without valgrind I get SIGSEGV here.)
The first bad commit is 1349d2790 again (but before 80ef92675 an assertion failure can be seen).
Best regards,
Alexander
pgsql-bugs by date: