Re: BUG #17406: Segmentation fault on GiST index after 14.2 upgrade

>
> Interesting! What's the backtrace from the crash?
>

Here's the backtrace:
(gdb) bt
#0 __GI_raise (sig=sig(at)entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x00007f1806417921 in __GI_abort () at abort.c:79
#2 0x00007f1806460967 in __libc_message (action=action(at)entry=do_abort,
fmt=fmt(at)entry=0x7f180658db0d "%s\n") at ../sysdeps/posix/libc_fatal.c:181
#3 0x00007f18064679da in malloc_printerr (str=str(at)entry=0x7f180658f818
"double free or corruption (out)") at malloc.c:5342
#4 0x00007f180646ef6a in _int_free (have_lock=0, p=0x560a0074ec70,
av=0x7f18067c2c40 <main_arena>) at malloc.c:4308
#5 __GI___libc_free (mem=0x560a0074ec80) at malloc.c:3134
#6 0x00005609ffa661d0 in AllocSetReset (context=0x560a00634d10) at
./build/../src/backend/utils/mmgr/aset.c:608
#7 0x00005609ffa6b879 in MemoryContextResetOnly (context=0x560a00634d10)
at ./build/../src/backend/utils/mmgr/mcxt.c:181
#8 0x00005609ffa6bae6 in MemoryContextResetOnly (context=<optimized out>)
at ./build/../src/backend/utils/mmgr/mcxt.c:154
#9 MemoryContextReset (context=<optimized out>) at
./build/../src/backend/utils/mmgr/mcxt.c:153
#10 0x00005609ff78b205 in ExecScan (node=0x560a00633040,
accessMtd=0x5609ff79c670 <FunctionNext>, recheckMtd=0x5609ff79c640
<FunctionRecheck>) at ./build/../src/backend/executor/execScan.c:181
#11 0x00005609ff78134d in ExecProcNode (node=0x560a00633040) at
./build/../src/include/executor/executor.h:257
#12 ExecutePlan (execute_once=<optimized out>, dest=0x560a00630608,
direction=<optimized out>, numberTuples=0, sendTuples=<optimized out>,
operation=CMD_SELECT, use_parallel_mode=<optimized out>,
planstate=0x560a00633040, estate=0x560a00632e18)
at ./build/../src/backend/executor/execMain.c:1551
#13 standard_ExecutorRun (queryDesc=0x560a00602448, direction=<optimized
out>, count=0, execute_once=<optimized out>) at
./build/../src/backend/executor/execMain.c:361
#14 0x00007f17fedfa595 in pgss_ExecutorRun (queryDesc=0x560a00602448,
direction=ForwardScanDirection, count=0, execute_once=<optimized out>) at
./build/../contrib/pg_stat_statements/pg_stat_statements.c:1003
#15 0x00005609ff906986 in PortalRunSelect (portal=portal(at)entry=0x560a006c7658,
forward=forward(at)entry=true, count=0, count(at)entry=9223372036854775807,
dest=dest(at)entry=0x560a00630608) at ./build/../src/backend/tcop/pquery.c:921
#16 0x00005609ff907ff8 in PortalRun (portal=portal(at)entry=0x560a006c7658,
count=count(at)entry=9223372036854775807, isTopLevel=isTopLevel(at)entry=true,
run_once=run_once(at)entry=true, dest=dest(at)entry=0x560a00630608,
altdest=altdest(at)entry=0x560a00630608,
qc=0x7ffcc729cbf0) at ./build/../src/backend/tcop/pquery.c:765
#17 0x00005609ff9038e9 in exec_simple_query (query_string=0x560a005de178
"SELECT * FROM gist_page_items(get_raw_page('region_ltree_path_idx_gist',
0), 'region_ltree_path_idx_gist');") at
./build/../src/backend/tcop/postgres.c:1214
#18 0x00005609ff905c4c in PostgresMain (argc=argc(at)entry=1,
argv=argv(at)entry=0x7ffcc729d0b0,
dbname=<optimized out>, username=<optimized out>) at
./build/../src/backend/tcop/postgres.c:4486
#19 0x00005609ff878e2a in BackendRun (port=<optimized out>, port=<optimized
out>) at ./build/../src/backend/postmaster/postmaster.c:4530
#20 BackendStartup (port=<optimized out>) at
./build/../src/backend/postmaster/postmaster.c:4252
#21 ServerLoop () at ./build/../src/backend/postmaster/postmaster.c:1745
#22 0x00005609ff879c68 in PostmasterMain (argc=5, argv=0x560a005d6dc0) at
./build/../src/backend/postmaster/postmaster.c:1417
#23 0x00005609ff5b283b in main (argc=5, argv=0x560a005d6dc0) at
./build/../src/backend/main/main.c:209

Also, I've looked into the database.
It has ltree in unpackaged state for quite some time, I suppose since 8.*
times. I've converted into extensions ltree and dblink.

Next, I've performed an upgrade again and the issue is still there.

I got approval to send a table with its data and index in the subject
datafile.
Taken from the v14 database.

--
Victor Yegorov