BUG #4814: Segmentation fault when using indexed prefix FT search

The following bug has been logged online:

Bug reference: 4814
Logged by: Dennis Noordsij
Email address: dennis(dot)noordsij(at)helsinki(dot)fi
PostgreSQL version: 8.4 SNAP 17MAY
Operating system: Linux
Description: Segmentation fault when using indexed prefix FT search
Details:

To replicate on latest 8.4 snapshot (17 May):

--------------------
begin;

create table foo (
ts tsvector not null
);

-- Without this index the query does not
-- crash.
create index foo_idx on foo using gin(ts);

insert into foo values (to_tsvector('Lore ipsum'));

select * from foo where 'ipsu:*'::tsquery @@ ts;

-- The query works correctly when not doing a
-- prefix search

abort;
--------------------

The EXPLAIN for the search query is:

QUERY PLAN
----------------------------------------------------------------------
Bitmap Heap Scan on foo (cost=4.30..14.45 rows=7 width=32)
Recheck Cond: ('''ipsu'':*'::tsquery @@ ts)
-> Bitmap Index Scan on foo_idx (cost=0.00..4.30 rows=7 width=0)
Index Cond: ('''ipsu'':*'::tsquery @@ ts)

Backtrace:

#0 0x0000000000000000 in ?? ()
#1 0x000000000075144d in FunctionCall4 (flinfo=0xd4c908, arg1=13968504,
arg2=47309168818128, arg3=1, arg4=13968480) at fmgr.c:1360
#2 0x00000000004b7480 in matchPartialInPendingList (ginstate=0xd4b0d8,
page=0x2b07063397e0 "", off=1, maxoff=3, value=13968504,
attrnum=1, datum=0x7fffa5883ae0, datumExtracted=0x7fffa5885ae0
"\001\001", strategy=1, extra_data=0xd52460 "") at ginget.c:858
#3 0x00000000004b794c in collectDatumForItem (scan=0xd4afb0,
pos=0x7fffa5885fa0) at ginget.c:991
#4 0x00000000004b7b45 in scanPendingInsert (scan=0xd4afb0, tbm=0xd4e2b8,
ntids=0x7fffa5886028) at ginget.c:1081
#5 0x00000000004b7ff4 in gingetbitmap (fcinfo=0x7fffa5886070) at
ginget.c:1229
#6 0x000000000075125e in FunctionCall2 (flinfo=0xd21330, arg1=13938608,
arg2=13951672) at fmgr.c:1308
#7 0x0000000000480696 in index_getbitmap (scan=0xd4afb0, bitmap=0xd4e2b8)
at indexam.c:670
#8 0x000000000059c2cd in MultiExecBitmapIndexScan (node=0xd4ad10) at
nodeBitmapIndexscan.c:91
#9 0x00000000005894db in MultiExecProcNode (node=0xd4ad10) at
execProcnode.c:501
#10 0x000000000059b643 in BitmapHeapNext (node=0xd338d0) at
nodeBitmapHeapscan.c:131
#11 0x0000000000593a44 in ExecScan (node=0xd338d0, accessMtd=0x59b494
<BitmapHeapNext>) at execScan.c:68
#12 0x000000000059bdaf in ExecBitmapHeapScan (node=0xd338d0) at
nodeBitmapHeapscan.c:429
#13 0x000000000058928e in ExecProcNode (node=0xd338d0) at
execProcnode.c:373
#14 0x00000000005a300e in ExecNestLoop (node=0xd32830) at
nodeNestloop.c:154
#15 0x000000000058930c in ExecProcNode (node=0xd32830) at
execProcnode.c:404
#16 0x0000000000586b61 in ExecutePlan (estate=0xd32310, planstate=0xd32830,
operation=CMD_SELECT, numberTuples=0,
direction=ForwardScanDirection, dest=0xd2fba0) at execMain.c:1504
#17 0x0000000000584df4 in standard_ExecutorRun (queryDesc=0xcefa20,
direction=ForwardScanDirection, count=0) at execMain.c:309
#18 0x0000000000584cfd in ExecutorRun (queryDesc=0xcefa20,
direction=ForwardScanDirection, count=0) at execMain.c:258
#19 0x000000000066a47e in PortalRunSelect (portal=0xd1ae40, forward=1
'\001', count=0, dest=0xd2fba0) at pquery.c:953
#20 0x000000000066a121 in PortalRun (portal=0xd1ae40,
count=9223372036854775807, isTopLevel=1 '\001', dest=0xd2fba0,
altdest=0xd2fba0, completionTag=0x7fffa5886aa0 "") at pquery.c:779
#21 0x000000000066490d in exec_simple_query (
query_string=0xcbe830 "select * from foo, to_tsquery('ipsu:*') as query
where query @@ ts;") at postgres.c:991
#22 0x000000000066867d in PostgresMain (argc=4, argv=0xc21178,
username=0xc21140 "developer") at postgres.c:3606
#23 0x0000000000632c0d in BackendRun (port=0xc423e0) at postmaster.c:3389
#24 0x00000000006321f4 in BackendStartup (port=0xc423e0) at
postmaster.c:3005
#25 0x000000000062fb0a in ServerLoop () at postmaster.c:1343
#26 0x000000000062f409 in PostmasterMain (argc=1, argv=0xc1e750) at
postmaster.c:1039
#27 0x00000000005bd216 in main (argc=1, argv=0xc1e750) at main.c:188