Re: BUG #17406: Segmentation fault on GiST index after 14.2 upgrade - Mailing list pgsql-bugs

From Victor Yegorov
Subject Re: BUG #17406: Segmentation fault on GiST index after 14.2 upgrade
Date
Msg-id CAGnEboiQ-cnhXceFa9WfXk7y06fuVVsf9WcmEdPerjqth8QJxA@mail.gmail.com
Whole thread Raw
In response to Re: BUG #17406: Segmentation fault on GiST index after 14.2 upgrade  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
Responses Re: BUG #17406: Segmentation fault on GiST index after 14.2 upgrade  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
List pgsql-bugs
Interesting! What's the backtrace from the crash?

Here's the backtrace:
(gdb) bt
#0  __GI_raise (sig=sig@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@entry=do_abort, fmt=fmt@entry=0x7f180658db0d "%s\n") at ../sysdeps/posix/libc_fatal.c:181
#3  0x00007f18064679da in malloc_printerr (str=str@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@entry=0x560a006c7658, forward=forward@entry=true, count=0, count@entry=9223372036854775807, dest=dest@entry=0x560a00630608) at ./build/../src/backend/tcop/pquery.c:921
#16 0x00005609ff907ff8 in PortalRun (portal=portal@entry=0x560a006c7658, count=count@entry=9223372036854775807, isTopLevel=isTopLevel@entry=true, run_once=run_once@entry=true, dest=dest@entry=0x560a00630608, altdest=altdest@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@entry=1, argv=argv@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
Attachment

pgsql-bugs by date:

Previous
From: "egashira.yusuke@fujitsu.com"
Date:
Subject: Reconnect a single connection used by multiple threads in embedded SQL in C application causes error.
Next
From: Andres Freund
Date:
Subject: Re: can't drop table due to reference from orphaned temp function