BUG #14134: segmentation fault with large table with gist index

The following bug has been logged on the website:

Bug reference:      14134
Logged by:          Jihyun Yu
Email address:      yjh0502@gmail.com
PostgreSQL version: 9.5.2
Operating system:   FreeBSD 10.3
Description:

Here's a stacktrace from a coredump:

#0  0x0000000000a020b9 in MemoryContextAlloc (context=0x0, size=984) at
mcxt.c:680
680             context->isReset = false;
[New Thread 802006400 (LWP 100856/<unknown>)]
(gdb) bt
#0  0x0000000000a020b9 in MemoryContextAlloc (context=0x0, size=984) at
mcxt.c:680
#1  0x0000000000a08198 in PrepareSortSupportComparisonShim (cmpFunc=1315,
ssup=0x8022cd108) at sortsupport.c:73
#2  0x0000000000a08484 in FinishSortSupportFunction (opfamily=1982,
opcintype=1186, ssup=0x8022cd108) at sortsupport.c:123
#3  0x0000000000a0837e in PrepareSortSupportFromOrderingOp (orderingOp=1332,
ssup=0x8022cd108) at sortsupport.c:150
#4  0x00000000006bc69e in ExecInitIndexScan (node=0x8022bcc00,
estate=0x8022cb030, eflags=16) at nodeIndexscan.c:970
#5  0x000000000069cec6 in ExecInitNode (node=0x8022bcc00,
estate=0x8022cb030, eflags=16) at execProcnode.c:200
#6  0x00000000006bf6c2 in ExecInitLimit (node=0x8022bf830,
estate=0x8022cb030, eflags=16) at nodeLimit.c:415
#7  0x000000000069d166 in ExecInitNode (node=0x8022bf830,
estate=0x8022cb030, eflags=16) at execProcnode.c:326
#8  0x000000000069898a in InitPlan (queryDesc=0x8022bfc90, eflags=16) at
execMain.c:957
#9  0x00000000006982bc in standard_ExecutorStart (queryDesc=0x8022bfc90,
eflags=16) at execMain.c:237
#10 0x0000000802403072 in _PG_init () from
/usr/local/lib/postgresql/pg_stat_statements.so
#11 0x00000000006980a2 in ExecutorStart (queryDesc=0x8022bfc90, eflags=0) at
execMain.c:137
#12 0x000000000061ad75 in ExplainOnePlan (plannedstmt=0x8022bfc00, into=0x0,
es=0x8021ef9e8,
    queryString=0x80208f030 "explain analyze select order_at from d_article
where deleted=false and root_id = parent_id order by order_at <->
'2016-03-01' limit 10;",
    params=0x0, planduration=0x7fffffffdc60) at explain.c:489
#13 0x000000000061a6e5 in ExplainOneQuery (query=0x8021efaa8, into=0x0,
es=0x8021ef9e8,
    queryString=0x80208f030 "explain analyze select order_at from d_article
where deleted=false and root_id = parent_id order by order_at <->
'2016-03-01' limit 10;", params=0x0)
    at explain.c:357
#14 0x000000000061a365 in ExplainQuery (stmt=0x802090720,
    queryString=0x80208f030 "explain analyze select order_at from d_article
where deleted=false and root_id = parent_id order by order_at <->
'2016-03-01' limit 10;",
    params=0x0, dest=0x8021ef958) at explain.c:245
#15 0x0000000000844379 in standard_ProcessUtility (parsetree=0x802090720,
    queryString=0x80208f030 "explain analyze select order_at from d_article
where deleted=false and root_id = parent_id order by order_at <->
'2016-03-01' limit 10;",
    context=PROCESS_UTILITY_TOPLEVEL, params=0x0, dest=0x8021ef958,
completionTag=0x7fffffffe240 "") at utility.c:658
#16 0x0000000802403492 in _PG_init () from
/usr/local/lib/postgresql/pg_stat_statements.so
#17 0x0000000000843b22 in ProcessUtility (parsetree=0x802090720,
    queryString=0x80208f030 "explain analyze select order_at from d_article
where deleted=false and root_id = parent_id order by order_at <->
'2016-03-01' limit 10;",
    context=PROCESS_UTILITY_TOPLEVEL, params=0x0, dest=0x8021ef958,
completionTag=0x7fffffffe240 "") at utility.c:330
#18 0x0000000000843688 in PortalRunUtility (portal=0x802207030,
utilityStmt=0x802090720, isTopLevel=1 '\001', dest=0x8021ef958,
completionTag=0x7fffffffe240 "") at pquery.c:1183
#19 0x0000000000842217 in FillPortalStore (portal=0x802207030, isTopLevel=1
'\001') at pquery.c:1057
#20 0x0000000000841e6a in PortalRun (portal=0x802207030,
count=9223372036854775807, isTopLevel=1 '\001', dest=0x802090f20,
altdest=0x802090f20, completionTag=0x7fffffffe460 "")
    at pquery.c:781
#21 0x000000000083d9a3 in exec_simple_query (
    query_string=0x80208f030 "explain analyze select order_at from d_article
where deleted=false and root_id = parent_id order by order_at <->
'2016-03-01' limit 10;")
    at postgres.c:1104
#22 0x000000000083ccdb in PostgresMain (argc=1, argv=0x80201de10,
dbname=0x80201dcc8 "board", username=0x80201dcb0 "root") at postgres.c:4030
#23 0x00000000007b1b7c in BackendRun (port=0x8020e51c0) at
postmaster.c:4239
#24 0x00000000007b11a4 in BackendStartup (port=0x8020e51c0) at
postmaster.c:3913
#25 0x00000000007adc87 in ServerLoop () at postmaster.c:1684
#26 0x00000000007ab5ff in PostmasterMain (argc=3, argv=0x7fffffffebd8) at
postmaster.c:1292
#27 0x00000000006f3f98 in main (argc=3, argv=0x7fffffffebd8) at main.c:228


The postgresql server crashed with segfault. Here's an index which causes
the crash:

create index concurrently d_article_gist_idx on d_article using btree_gist
(order_at) where deleted=false and parent_id = root_id

'd_article' table contains ~4M rows and server runs on machine with 2GB of
RAM.