Thread: segv's on CREATE INDEX with recent HEAD...
Don't know whether or not this is preferred here or on hackers, but, I
just updated my development database to a snapshot from today and have
been getting the following backtrace when importing a dump from before
earlier today. It looks as though something's tromping on variable.
pid 68526 (postgres), uid 70: exited on signal 11 (core dumped)
#0 0x0810c29d in ExecEvalVar (variable=0x2, econtext=0x83cc0a0, isNull=0xbfbfed70 "") at execQual.c:403
#1 0x0810aa67 in ExecEvalExpr (expression=0x83cc208, econtext=0x83cc0a0, isNull=0xbfbfed70 "", isDone=0xbfbfecbc) at
execQual.c:1985
#2 0x08109e60 in ExecMakeFunctionResult (fcache=0x83cc100, econtext=0x83cc0a0, isNull=0xbfbfee2b "", isDone=0x0) at
execQual.c:641
#3 0x0810ab46 in ExecEvalExpr (expression=0x83cc100, econtext=0x83cc0a0, isNull=0xbfbfee2b "", isDone=0x83cc0a0) at
execQual.c:2012
#4 0x0810bcd9 in ExecEvalExprSwitchContext (expression=0x8316b70, econtext=0x83cc0a0, isNull=0x8316b70 "\b",
isDone=0x8316b70)
at execQual.c:2129
#5 0x080a5a0c in FormIndexDatum (indexInfo=0x83f9c18, heapTuple=0x8351938, heapDescriptor=0x8316b70, estate=0x83cc018,
datum=0xbfbfeec0,
nullv=0xbfbfeea0 "\b)/\b") at index.c:955
#6 0x080a6529 in IndexBuildHeapScan (heapRelation=0xbfbfeec0, indexRelation=0x8416468, indexInfo=0x83f9c18,
callback=0x8087eb0 <btbuildCallback>, callback_state=0xbfbfef90) at index.c:1625
#7 0x08086e1b in btbuild (fcinfo=0x8316b70) at nbtree.c:129
#8 0x081ffd60 in OidFunctionCall3 (functionId=137456496, arg1=137456496, arg2=137456496, arg3=137456496) at
fmgr.c:1277
#9 0x080a62a9 in index_build (heapRelation=0x8316b70, indexRelation=0x2, indexInfo=0x8316b70) at index.c:1398
#10 0x080a530e in index_create (heapRelationId=33576, indexRelationName=0x834c350 "t_udx", indexInfo=0x83f9c18,
accessMethodObjectId=137456496, classObjectId=0x83f9ca0, primary=0 '\0', isconstraint=0 '\0',
allow_system_table_mods=0'\0')
at index.c:750
#11 0x080e332d in DefineIndex (heapRelation=0x83f9c18, indexRelationName=0x834c350 "t_udx", accessMethodName=0x82165c6
"btree",
attributeList=0x834c510, unique=1 '\001', primary=0 '\0', isconstraint=0 '\0', predicate=0x0, rangetable=0x8328) at
indexcmds.c:238
#12 0x0818709e in ProcessUtility (parsetree=0x834c528, dest=0x0, completionTag=0x834c528 "\002") at utility.c:736
#13 0x08185299 in PortalRunUtility (portal=0x83a0018, query=0x0, dest=0x834c568, completionTag=0x0) at pquery.c:737
#14 0x08185513 in PortalRunMulti (portal=0x83a0018, dest=0x834c568, altdest=0x834c568, completionTag=0xbfbff3a0 "") at
pquery.c:801
#15 0x08184df4 in PortalRun (portal=0x83a0018, count=2147483647, dest=0x834c568, altdest=0x8316b70,
completionTag=0xbfbff3a0"")
at pquery.c:465
#16 0x081834b3 in exec_simple_query (query_string=0x834c030 "CREATE UNIQUE INDEX t_udx ON s.t (LOWER(a));")
at postgres.c:853
#17 0x08181eea in PostgresMain (argc=4, argv=0x82db9d8, username=0x82db9a8 "nxadba") at postgres.c:2730
#18 0x0815948d in BackendFork (port=0x82e6000) at postmaster.c:2473
#19 0x08158e54 in BackendStartup (port=0x82e6000) at postmaster.c:2095
#20 0x081575ec in ServerLoop () at postmaster.c:1049
#21 0x08156e68 in PostmasterMain (argc=1, argv=0x82d9030) at postmaster.c:829
#22 0x08123b63 in main (argc=1, argv=0xbfbffcb8) at main.c:211
#23 0x0806c0a5 in _start ()
It looks like the change that went in on 1.128 is the culprit simply
because it's the only change in this function since the last stable
snapshot. I can consitently reproduce this with one of my schemas if
someone needs more debugging information, point me in the right
direction for where you'd like me to attach gdb. I haven't been able
to get a use case bottled up, but with a backtrace, I'm not that
worried.
-sc
--
Sean Chittenden
Sean Chittenden <sean@chittenden.org> writes:
> Don't know whether or not this is preferred here or on hackers, but, I
> just updated my development database to a snapshot from today and have
> been getting the following backtrace when importing a dump from before
> earlier today. It looks as though something's tromping on variable.
Argh! Can't believe that snuck through my testing. Fix committed
(and regression test case added...)
regards, tom lane
> > Don't know whether or not this is preferred here or on hackers, > > but, I just updated my development database to a snapshot from > > today and have been getting the following backtrace when importing > > a dump from before earlier today. It looks as though something's > > tromping on variable. > > Argh! Can't believe that snuck through my testing. Fix committed > (and regression test case added...) Thanks, this fixed loading my dump! Looks like the protocol stuff is much more solid now too, SELECT * FROM pg_class doesn't return garbage any more. :) ... looks like everything is nominal in HEAD again. *cheers* Thanks Tom! -sc PS What's the dilly with the server(s)? I haven't gotten a commit message all day, but CVSup and anoncvs picked up the change. -- Sean Chittenden
Sean Chittenden <sean@chittenden.org> writes:
> PS What's the dilly with the server(s)? I haven't gotten a commit
> message all day, but CVSup and anoncvs picked up the change.
Well, the CVS master server has been pretty much 100% through this
whole rigmarole (kudos to Marc for keeping up what *had* to be up ;-))
The anoncvs mirror was busted for a couple days but has been okay since
then, AFAIK. The pgsql-committers list is still, uh, AWOL. I get the
impression that the listserv doesn't think the CVS server is authorized
to send mail to the list, and that Marc has been manually approving
batches of mail every couple days but hasn't got round to locating the
real problem yet. I trust he'll get it fixed before much longer though
...
regards, tom lane
> Sean Chittenden <sean@chittenden.org> writes:
> > PS What's the dilly with the server(s)? I haven't gotten a commit
> > message all day, but CVSup and anoncvs picked up the change.
>
> Well, the CVS master server has been pretty much 100% through this
> whole rigmarole (kudos to Marc for keeping up what *had* to be up ;-))
> The anoncvs mirror was busted for a couple days but has been okay since
> then, AFAIK. The pgsql-committers list is still, uh, AWOL. I get the
> impression that the listserv doesn't think the CVS server is authorized
> to send mail to the list, and that Marc has been manually approving
> batches of mail every couple days but hasn't got round to locating the
> real problem yet. I trust he'll get it fixed before much longer though
> ...
Hardware problems are the worst. Best of Marc. Well, normally you're
good about committing things in batches, but I'm not sure if I'm
building against a complete/up to date version, but here is some
regression.diff fun to digest. Looks like expected/misc.out and
./expected/sanity_check.out need to be updated and there's something
wrong with triggers/constraints:
*** ./expected/constraints.out Wed May 28 23:26:42 2003
--- ./results/constraints.out Wed May 28 23:28:15 2003
***************
*** 191,210 ****
CREATE TABLE INSERT_CHILD (cx INT default 42,
cy INT CHECK (cy > x))
INHERITS (INSERT_TBL);
INSERT INTO INSERT_CHILD(x,z,cy) VALUES (7,-7,11);
INSERT INTO INSERT_CHILD(x,z,cy) VALUES (7,-7,6);
! ERROR: ExecInsert: rejected due to CHECK constraint "insert_child_cy" on "insert_child"
INSERT INTO INSERT_CHILD(x,z,cy) VALUES (6,-7,7);
! ERROR: ExecInsert: rejected due to CHECK constraint "$1" on "insert_child"
INSERT INTO INSERT_CHILD(x,y,z,cy) VALUES (6,'check failed',-6,7);
! ERROR: ExecInsert: rejected due to CHECK constraint "insert_con" on "insert_child"
SELECT * FROM INSERT_CHILD;
! x | y | z | cx | cy
! ---+--------+----+----+----
! 7 | -NULL- | -7 | 42 | 11
! (1 row)
!
DROP TABLE INSERT_CHILD;
--
-- Check constraints on INSERT INTO
--
--- 191,209 ----
CREATE TABLE INSERT_CHILD (cx INT default 42,
cy INT CHECK (cy > x))
INHERITS (INSERT_TBL);
+ ERROR: RelationClearRelation: relation 135137 deleted while still in use
INSERT INTO INSERT_CHILD(x,z,cy) VALUES (7,-7,11);
+ ERROR: Relation "insert_child" does not exist
INSERT INTO INSERT_CHILD(x,z,cy) VALUES (7,-7,6);
! ERROR: Relation "insert_child" does not exist
INSERT INTO INSERT_CHILD(x,z,cy) VALUES (6,-7,7);
! ERROR: Relation "insert_child" does not exist
INSERT INTO INSERT_CHILD(x,y,z,cy) VALUES (6,'check failed',-6,7);
! ERROR: Relation "insert_child" does not exist
SELECT * FROM INSERT_CHILD;
! ERROR: Relation "insert_child" does not exist
DROP TABLE INSERT_CHILD;
+ ERROR: table "insert_child" does not exist
--
-- Check constraints on INSERT INTO
--
======================================================================
*** ./expected/triggers.out Sat Nov 23 10:13:22 2002
--- ./results/triggers.out Wed May 28 23:28:15 2003
***************
*** 87,92 ****
--- 87,93 ----
NOTICE: check_pkeys_fkey_cascade: 1 tuple(s) of fkeys are deleted
NOTICE: check_pkeys_fkey_cascade: 1 tuple(s) of fkeys2 are deleted
DROP TABLE pkeys;
+ ERROR: Relation 120339 does not exist
DROP TABLE fkeys;
DROP TABLE fkeys2;
-- -- I've disabled the funny_dup17 test because the new semantics
======================================================================
*** ./expected/sanity_check.out Wed May 28 09:04:02 2003
--- ./results/sanity_check.out Wed May 28 23:28:29 2003
***************
*** 58,68 ****
pg_statistic | t
pg_trigger | t
pg_type | t
road | t
shighway | t
tenk1 | t
tenk2 | t
! (52 rows)
--
-- another sanity check: every system catalog that has OIDs should have
--- 58,69 ----
pg_statistic | t
pg_trigger | t
pg_type | t
+ pkeys | t
road | t
shighway | t
tenk1 | t
tenk2 | t
! (53 rows)
--
-- another sanity check: every system catalog that has OIDs should have
======================================================================
*** ./expected/misc.out Wed May 28 23:26:42 2003
--- ./results/misc.out Wed May 28 23:28:39 2003
***************
*** 633,638 ****
--- 633,639 ----
onek2
path_tbl
person
+ pkeys
point_tbl
polygon_tbl
ramp
***************
*** 657,663 ****
toyemp
varchar_tbl
xacttest
! (93 rows)
--SELECT name(equipment(hobby_construct(text 'skywalking', text 'mer'))) AS equip_name;
SELECT hobbies_by_name('basketball');
--- 658,664 ----
toyemp
varchar_tbl
xacttest
! (94 rows)
--SELECT name(equipment(hobby_construct(text 'skywalking', text 'mer'))) AS equip_name;
SELECT hobbies_by_name('basketball');
======================================================================
Sorry for the bad news... or incomplete Sup. This a local problem
(incomplete checkout?) or is there something else going on? -sc
--
Sean Chittenden
Sean Chittenden <sean@chittenden.org> writes:
> CREATE TABLE INSERT_CHILD (cx INT default 42,
> cy INT CHECK (cy > x))
> INHERITS (INSERT_TBL);
> + ERROR: RelationClearRelation: relation 135137 deleted while still in use
Hm. Anyone else seeing this? I just did a dozen or so "make check"s on
a fresh build from CVS tip ... no sign of trouble ...
regards, tom lane