BUG #17589: Invalid read at array_positions

The following bug has been logged on the website:

Bug reference: 17589
Logged by: Robins Tharakan
Email address: tharakan(at)gmail(dot)com
PostgreSQL version: 14.5
Operating system: Ubuntu 20.04
Description:

A valgrind enabled sqlsmith run threw this error.

==00:02:14:21.521 213966== VALGRINDERROR-BEGIN
==00:02:14:21.522 213966== Invalid read of size 4
==00:02:14:21.522 213966==    at 0x78169C: array_positions
(array_userfuncs.c:806)
==00:02:14:21.522 213966==    by 0x49C841: ExecInterpExpr
(execExprInterp.c:741)
==00:02:14:21.522 213966==    by 0x49ED30: ExecInterpExprStillValid
(execExprInterp.c:1882)
==00:02:14:21.522 213966==    by 0x4BABE5: ExecEvalExprSwitchContext
(executor.h:343)
==00:02:14:21.522 213966==    by 0x4BAC5D: ExecProject (executor.h:377)
==00:02:14:21.522 213966==    by 0x4BB11E: ExecScan (execScan.c:238)
==00:02:14:21.522 213966==    by 0x4FD1F8: ExecSeqScan (nodeSeqscan.c:112)
==00:02:14:21.522 213966==    by 0x4B6C54: ExecProcNodeFirst
(execProcnode.c:463)
==00:02:14:21.522 213966==    by 0x4F257B: ExecProcNode (executor.h:259)
==00:02:14:21.522 213966==    by 0x4F7CFC: ExecModifyTable
(nodeModifyTable.c:3529)
==00:02:14:21.522 213966==    by 0x4B6C54: ExecProcNodeFirst
(execProcnode.c:463)
==00:02:14:21.522 213966==    by 0x4AA229: ExecProcNode (executor.h:259)
==00:02:14:21.522 213966==  Address 0x4ed9d28 is 344 bytes inside a block of
size 8,192 alloc'd
==00:02:14:21.522 213966==    at 0x483B7F3: malloc (in
/usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==00:02:14:21.522 213966==    by 0x93DB39: AllocSetContextCreateInternal
(aset.c:469)
==00:02:14:21.522 213966==    by 0x4C01BE: CreateExprContextInternal
(execUtils.c:253)
==00:02:14:21.522 213966==    by 0x4C02A6: CreateExprContext
(execUtils.c:303)
==00:02:14:21.522 213966==    by 0x4C0541: ExecAssignExprContext
(execUtils.c:482)
==00:02:14:21.522 213966==    by 0x4E7CBE: ExecInitIndexScan
(nodeIndexscan.c:1078)
==00:02:14:21.522 213966==    by 0x4B668D: ExecInitNode
(execProcnode.c:219)
==00:02:14:21.522 213966==    by 0x4FA9EB: ExecInitNestLoop
(nodeNestloop.c:302)
==00:02:14:21.522 213966==    by 0x4B685E: ExecInitNode
(execProcnode.c:297)
==00:02:14:21.522 213966==    by 0x4EA43B: ExecInitLimit (nodeLimit.c:478)
==00:02:14:21.522 213966==    by 0x4B6A4B: ExecInitNode
(execProcnode.c:380)
==00:02:14:21.522 213966==    by 0x4AB719: InitPlan (execMain.c:938)
==00:02:14:21.522 213966==
==00:02:14:21.522 213966== VALGRINDERROR-END

Version: 93f2349c36(at)master

$ uname -a
Linux ip-172-31-3-183 5.15.0-1015-aws #19~20.04.1-Ubuntu SMP Wed Jun 22
19:07:51 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Command used:
valgrind --leak-check=no --track-origins=yes --read-var-info=yes
--gen-suppressions=all --suppressions=${PGSOURCE}/src/tools/valgrind.supp
--time-stamp=yes --error-markers=VALGRINDERROR-BEGIN,VALGRINDERROR-END
--log-file=${PGTEMP}/valgrind/%p.log --trace-children=yes
${PGTEMP}/bin/pg_ctl -D ${PGTEMP}/data -l ${PGTEMP}/logfile start

I can't reproduce this but I'd be interested in knowing whether
another set of (valgrind or other) flags may help better in
triaging here.

If nothing else works, I'll try to enable log_statement=all for
future runs, but that really slows things down and I'd prefer to
keep that as a last resort.

Thanks