Hi,
this is a follow-up to the message I posted to the thread about
additional info in GIN.
I've applied all three patches (ginaddinfo7.patch, gin_fast_scan.4.patch
and gin_ordering.4.patch) onto commit b8fd1a09. I ended up with two
definitions of ‘cmpEntries’ in ginget.c, but I suppose this is due to
split of the patch into multiple pieces. The definitions are exactly the
same so I've commented out the second one.
After applying fast scan the queries fail with 'buffer is not owned by
resource owner Portal' errors, the ordering patch causes segmentation
faults when loading the data.
Loading the data is basically a bunch of INSERT statements into
"messages" table, with a GIN index on the message body. So the table and
index are defined like this:
CREATE TABLE messages (
id SERIAL PRIMARY KEY,
parent_id INT REFERENCES messages(id),
thread_id INT,
level INT,
hash_id VARCHAR(32) NOT NULL UNIQUE,
list VARCHAR(32) NOT NULL REFERENCES lists(id),
message_id VARCHAR(200),
in_reply_to TEXT[],
refs TEXT[],
sent TIMESTAMP,
subject TEXT,
author TEXT,
body_plain TEXT,
body_tsvector tsvector,
subject_tsvector tsvector,
headers HSTORE,
raw_message TEXT
);
CREATE INDEX message_body_idx on messages using gin(body_tsvector);
I've observed about three failure scenarios:
1) autovacuum runs VACUUM on the 'messages' table and fails, killing
all the connections, with this message in the server log
LOG: server process (PID 16611) was terminated by signal
11: Segmentation fault
DETAIL: Failed process was running: autovacuum: ANALYZE
public.messages
2) manual run of VACUUM on the table, with about the same result and
this output on the console (and the same segfault in the server log)
archie=# vacuum messages;
WARNING: relation "messages" page 6226 is uninitialized --- fixing
WARNING: relation "messages" page 6227 is uninitialized --- fixing
WARNING: relation "messages" page 6228 is uninitialized --- fixing
WARNING: relation "messages" page 6229 is uninitialized --- fixing
WARNING: relation "messages" page 6230 is uninitialized --- fixing
WARNING: relation "messages" page 6231 is uninitialized --- fixing
WARNING: relation "messages" page 6232 is uninitialized --- fixing
WARNING: relation "messages" page 6233 is uninitialized --- fixing
The connection to the server was lost. Attempting reset: Failed.
3) disabled autovacuum, the load fails (always at exactly the same
place) - I have collected a backtrace from gdb (after recompiling
with disabled optimization), see the attachment.
All three scenarios might actually be caused by the same bug, as I've
checked the backtrace for the VACUUM and it fails at exactly the same
place as the third case.
regards
Tomas
Program received signal SIGSEGV, Segmentation fault.
0x000000000047517d in ginDataPageLeafReadItemPointer (ptr=0x15f00ae <Address
0x15f00ae out of bounds>, iptr=0x7fff1781d340, addInfoIsNull=0x7fff1781d2d7 "")
at ../../../../src/include/access/gin_private.h:866
866 v = *ptr;
(gdb) bt
#0 0x000000000047517d in ginDataPageLeafReadItemPointer (ptr=0x15f00ae
<Address 0x15f00ae out of bounds>, iptr=0x7fff1781d340,
addInfoIsNull=0x7fff1781d2d7 "") at
../../../../src/include/access/gin_private.h:866
#1 0x00000000004752ae in ginDataPageLeafRead (ptr=0x15f00ae <Address 0x15f00ae
out of bounds>, attnum=1, iptr=0x7fff1781d340, addInfo=0x7fff1781d348,
addInfoIsNull=0x7fff1781d347 "", ginstate=0x7fff1781d9c0)
at ../../../../src/include/access/gin_private.h:916
#2 0x00000000004779d6 in dataSplitPageLeaf (btree=0x8b97580, lbuf=33601,
rbuf=33602, off=1018, prdata=0x7fff1781d428) at gindatapage.c:954
#3 0x0000000000478d0d in dataSplitPage (btree=0x8b97580, lbuf=33601,
rbuf=33602, off=1018, prdata=0x7fff1781d428) at gindatapage.c:1262
#4 0x000000000047a056 in ginInsertValue (btree=0x8b97580, stack=0x8b98748,
buildStats=0x0) at ginbtree.c:385
#5 0x00000000004793d1 in ginInsertItemPointers (ginstate=0x7fff1781d9c0,
attnum=1, gdi=0x8b97580, items=0x43c6726, addInfo=0x3a41b08,
addInfoIsNull=0x8b97b31 "", nitem=1795, buildStats=0x0) at gindatapage.c:1414
#6 0x000000000046f7b2 in buildFreshLeafTuple (ginstate=0x7fff1781d9c0,
attnum=1, key=49986944, category=0 '\000', items=0x43c4f50, addInfo=0x3a3fb40,
addInfoIsNull=0x8b97738 "", nitem=2812, buildStats=0x0) at gininsert.c:418
#7 0x000000000046faf0 in ginEntryInsert (ginstate=0x7fff1781d9c0, attnum=1,
key=49986944, category=0 '\000', items=0x43c4f50, addInfo=0x3a3fb40,
addInfoIsNull=0x8b97738 "", nitem=2812, buildStats=0x0) at gininsert.c:512
#8 0x00000000004859c3 in ginInsertCleanup (ginstate=0x7fff1781d9c0,
vac_delay=0 '\000', stats=0x0) at ginfast.c:960
#9 0x000000000048425a in ginHeapTupleFastInsert (ginstate=0x7fff1781d9c0,
collector=0x7fff1781d9a0) at ginfast.c:440
#10 0x00000000004707c8 in gininsert (fcinfo=0x7fff17820db0) at gininsert.c:851
#11 0x000000000083d8c8 in FunctionCall6Coll (flinfo=0x2ae3b10, collation=0,
arg1=140262651022800, arg2=140733587788336, arg3=140733587788304,
arg4=48294676, arg5=140262650958704, arg6=0) at fmgr.c:1480
#12 0x00000000004ae8ec in index_insert (indexRelation=0x7f91717d4dd0,
values=0x7fff17821230, isnull=0x7fff17821210 "", heap_t_ctid=0x2e0eb14,
heapRelation=0x7f91717c5370, checkUnique=UNIQUE_CHECK_NO) at indexam.c:223
#13 0x0000000000609959 in ExecInsertIndexTuples (slot=0x2b27f20,
tupleid=0x2e0eb14, estate=0x2def090) at execUtils.c:1103
#14 0x000000000061bcfc in ExecInsert (slot=0x2b27f20, planSlot=0x2df0e98,
estate=0x2def090, canSetTag=1 '\001') at nodeModifyTable.c:268
#15 0x000000000061cdd1 in ExecModifyTable (node=0x2defd80) at
nodeModifyTable.c:994
#16 0x00000000005fcb0c in ExecProcNode (node=0x2defd80) at execProcnode.c:377
#17 0x00000000005fadb0 in ExecutePlan (estate=0x2def090, planstate=0x2defd80,
operation=CMD_INSERT, sendTuples=0 '\000', numberTuples=0,
direction=ForwardScanDirection, dest=0x2f7f7c0) at execMain.c:1470
#18 0x00000000005f9232 in standard_ExecutorRun (queryDesc=0x2a06cb0,
direction=ForwardScanDirection, count=0) at execMain.c:306
#19 0x00000000005f9131 in ExecutorRun (queryDesc=0x2a06cb0,
direction=ForwardScanDirection, count=0) at execMain.c:254
#20 0x000000000072822e in ProcessQuery (plan=0x2f7f6e0,
sourceText=0x2de2f10 "INSERT INTO messages (list, message_id, in_reply_to,
refs, sent, subject, author, body_plain, headers, raw_message) VALUES
('pgsql-general',
'[email protected]."...,
params=0x0, dest=0x2f7f7c0, completionTag=0x7fff17821830 "") at pquery.c:185
#21 0x000000000072997f in PortalRunMulti (portal=0x294f270, isTopLevel=1
'\001', dest=0x2f7f7c0, altdest=0x2f7f7c0, completionTag=0x7fff17821830 "") at
pquery.c:1279
#22 0x0000000000728ffe in PortalRun (portal=0x294f270,
count=9223372036854775807, isTopLevel=1 '\001', dest=0x2f7f7c0,
altdest=0x2f7f7c0, completionTag=0x7fff17821830 "") at pquery.c:816
#23 0x0000000000723362 in exec_simple_query (
query_string=0x2de2f10 "INSERT INTO messages (list, message_id,
in_reply_to, refs, sent, subject, author, body_plain, headers, raw_message)
VALUES ('pgsql-general',
'[email protected]."...)
at postgres.c:1048
#24 0x000000000072734f in PostgresMain (argc=1, argv=0x292dea0,
dbname=0x292de88 "archie", username=0x292de70 "tomas") at postgres.c:3985
#25 0x00000000006cf95e in BackendRun (port=0x294c1c0) at postmaster.c:3987
#26 0x00000000006cf107 in BackendStartup (port=0x294c1c0) at postmaster.c:3676
#27 0x00000000006cbb89 in ServerLoop () at postmaster.c:1577
#28 0x00000000006cb36e in PostmasterMain (argc=3, argv=0x292b990) at
postmaster.c:1246
#29 0x000000000063d9c5 in main (argc=3, argv=0x292b990) at main.c:196
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
