Crash on UPDATE in 7.0beta3

From: Magnus Hagander <mha(at)sollentuna(dot)net>
To: "'pgsql-hackers(at)postgresql(dot)org'" <pgsql-hackers(at)postgresql(dot)org>
Subject: Crash on UPDATE in 7.0beta3
Date: 2000-04-02 14:32:29
Message-ID: 215896B6B5E1CF11BC5600805FFEA82103046082@sirius.edu.sollentuna.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello!

When running multiple concurrent backends on my benchmark database, I see
consistent crashing when running with 8 clients, and sporadic crashes when
running with 4. After the crash, at least one index is broken, so if I run
it again, it will crash on that. When I rebuild my indexes, I get back to
the same crash.
It dies on the same query every time (but only when I have many concurrent
backends - I can run it "alone" from psql without any problem).

My platform is Linux 2.2.14 running on a Dual Pentium-III 550MHz with 384Mb
RAM.

An example gdb backtrace:

#0 ExecEvalVar (variable=0x8239910, econtext=0x8239fe0, isNull=0x823aac9
"")
at execQual.c:275
#1 0x80a31ab in ExecEvalExpr (expression=0x8239910, econtext=0x8239fe0,
isNull=0x823aac9 "", isDone=0xbfffe59f "\001\020\022") at
execQual.c:1203
#2 0x80a2d07 in ExecEvalFuncArgs (fcache=0x823ab58, econtext=0x8239fe0,
argList=0x82398f8, argV=0xbfffe5a0, argIsDone=0xbfffe59f "\001\020\022")
at execQual.c:634
#3 0x80a2dbb in ExecMakeFunctionResult (node=0x82398a8,
arguments=0x82398f8,
econtext=0x8239fe0, isNull=0xbfffe67e "",
isDone=0xbfffe61f
"\bPæÿ¿\"2\n\b\200\230#\bà\237#\b~æÿ¿`\236\023\bP\231#\bà\237#\b`æÿ¿ \t\017\
b") at execQual.c:710
#4 0x80a2f2d in ExecEvalOper (opClause=0x8239880, econtext=0x8239fe0,
isNull=0xbfffe67e "") at execQual.c:896
#5 0x80a3222 in ExecEvalExpr (expression=0x8239880, econtext=0x8239fe0,
isNull=0xbfffe67e "", isDone=0xbfffe67f
"\001àæÿ¿no\n\bP\231#\bà\237#\b")
at execQual.c:1238
#6 0x80a32ee in ExecQual (qual=0x8239950, econtext=0x8239fe0,
resultForNull=0 '\000') at execQual.c:1365
#7 0x80a6f6e in IndexNext (node=0x8239320) at nodeIndexscan.c:142
#8 0x80a3741 in ExecScan (node=0x8239320, accessMtd=0x80a6e80 <IndexNext>)
at execScan.c:103
#9 0x80a7123 in ExecIndexScan (node=0x8239320) at nodeIndexscan.c:287
#10 0x80a1ec9 in ExecProcNode (node=0x8239320, parent=0x8238be0)
at execProcnode.c:272
#11 0x80a85ab in ExecNestLoop (node=0x8238be0, parent=0x8238be0)
at nodeNestloop.c:192
#12 0x80a1eda in ExecProcNode (node=0x8238be0, parent=0x8238be0)
at execProcnode.c:280
#13 0x80a1c00 in EvalPlanQualNext (estate=0x8235ed0) at execMain.c:1980
#14 0x80a1bd3 in EvalPlanQual (estate=0x8235ed0, rti=1, tid=0xbfffe8b8)
at execMain.c:1966
#15 0x80a13f9 in ExecReplace (slot=0x82364a0, tupleid=0xbfffe928,
estate=0x8235ed0) at execMain.c:1535
#16 0x80a1071 in ExecutePlan (estate=0x8235ed0, plan=0x8235bb8,
operation=CMD_UPDATE, offsetTuples=0, numberTuples=0,
direction=ForwardScanDirection, destfunc=0x8237ad8) at execMain.c:1202
#17 0x80a060e in ExecutorRun (queryDesc=0x8236028, estate=0x8235ed0,
feature=3, limoffset=0x0, limcount=0x0) at execMain.c:325
#18 0x80fdbb5 in ProcessQueryDesc (queryDesc=0x8236028, limoffset=0x0,
limcount=0x0) at pquery.c:310
#19 0x80fdc41 in ProcessQuery (parsetree=0x82282a8, plan=0x8235bb8,
dest=Remote) at pquery.c:353
#20 0x80fc4cc in pg_exec_query_dest (
query_string=0x81ab248 "UPDATE items SET
itemsinstock=itemsinstock-order_items.amount WHERE
items.itemid=order_items.itemid AND order_items.orderid=467134",
dest=Remote, aclOverride=0) at postgres.c:719
#21 0x80fc392 in pg_exec_query (
query_string=0x81ab248 "UPDATE items SET
itemsinstock=itemsinstock-order_items.amount WHERE
items.itemid=order_items.itemid AND order_items.orderid=467134") at
postgres.c:607
#22 0x80fd533 in PostgresMain (argc=8, argv=0xbffff050, real_argc=8,
real_argv=0xbffffa04) at postgres.c:1642
#23 0x80e5f42 in DoBackend (port=0x81d3d80) at postmaster.c:1953
#24 0x80e5b1a in BackendStartup (port=0x81d3d80) at postmaster.c:1722
#25 0x80e4ce9 in ServerLoop () at postmaster.c:994
#26 0x80e46be in PostmasterMain (argc=8, argv=0xbffffa04) at
postmaster.c:700
#27 0x80b1dfb in main (argc=8, argv=0xbffffa04) at main.c:93

The line of crash is:
275 heapTuple = slot->val;

And this is because:
(gdb) print slot
$1 = (TupleTableSlot *) 0x0

Input to the switch() statement used to set slot is:
(gdb) print variable->varno
$3 = 65001
(gdb) print econtext->ecxt_scantuple
$5 = (TupleTableSlot *) 0x8238a38
(gdb) print econtext->ecxt_innertuple
$6 = (TupleTableSlot *) 0x0
(gdb) print econtext->ecxt_outertuple
$7 = (TupleTableSlot *) 0x0

Seems it wants to use the ecxt_outertuple, but it's NULL. That's about as
far as I can get :-)

Table definitions used:
CREATE TABLE items (
itemid int not null,
description varchar(128) not null,
price int,
itemsinstock int,
supplier int not null
);
CREATE UNIQUE INDEX items_id_idx ON items (itemid);
CREATE INDEX items_desc_idx ON items (description);
CREATE INDEX items_supp_idx ON items (supplier);
CREATE TABLE order_items (
orderid int not null,
itemid int not null,
amount int not null
);
CREATE UNIQUE INDEX order_items_both_idx ON order_items (orderid, itemid);
CREATE INDEX order_items_order_idx ON order_items (orderid);
CREATE INDEX order_items_item_idx ON order_items (itemid);

Items has ~ 10,000 rows, order_items has ~22 million.

//Magnus

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hiroshi Inoue 2000-04-02 15:16:28 RE: slow join on postgresql6.5
Previous Message Bruce Momjian 2000-04-02 14:18:10 Re: src/test/locale/de_DE.ISO-8859-1