Re: SSI bug? - Mailing list pgsql-hackers

From yamt@mwd.biglobe.ne.jp (YAMAMOTO Takashi)
Subject Re: SSI bug?
Date
Msg-id 20110216221335.C9A2119CF21@mail.netbsd.org
Whole thread Raw
In response to Re: SSI bug?  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Responses Re: SSI bug?  (Dan Ports <drkp@csail.mit.edu>)
List pgsql-hackers
hi,

might be unrelated to the loop problem, but...

i got the following SEGV when runnning vacuum on a table.
(the line numbers in predicate.c is different as i have local modifications.)
oldlocktag.myTarget was NULL.
it seems that TransferPredicateLocksToNewTarget sometimes use stack garbage
for newpredlocktag.myTarget.  vacuum on the table succeeded with the attached
patch.  the latter part of the patch was necessary to avoid targetList
corruption, which later seems to make DeleteChildTargetLocks loop inifinitely.

YAMAMOTO Takashi

#0  0x0823cf6c in PredicateLockAcquire (targettag=0xbfbfa734)   at predicate.c:1835
#1  0x0823f18a in PredicateLockPage (relation=0x99b4dcf0, blkno=1259)   at predicate.c:2206
#2  0x080ac978 in _bt_search (rel=0x99b4dcf0, keysz=2, scankey=0x99a05040,    nextkey=0 '\0', bufP=0xbfbfa894,
access=1)at nbtsearch.c:97
 
#3  0x080a996d in _bt_pagedel (rel=0x99b4dcf0, buf=<value optimized out>,    stack=0x0) at nbtpage.c:1059
#4  0x080aacc2 in btvacuumscan (info=0xbfbfbcc4, stats=0x99a01328,    callback=0x8184d50 <lazy_tid_reaped>,
callback_state=0x99a012e0,   cycleid=13675) at nbtree.c:981
 
#5  0x080ab15c in btbulkdelete (fcinfo=0xbfbfb9e0) at nbtree.c:573
#6  0x082fde74 in FunctionCall4 (flinfo=0x99b86958, arg1=3217013956, arg2=0,    arg3=135810384, arg4=2577404640) at
fmgr.c:1437
#7  0x080a4fd0 in index_bulk_delete (info=0xbfbfbcc4, stats=0x0,    callback=0x8184d50 <lazy_tid_reaped>,
callback_state=0x99a012e0)  at indexam.c:738
 
#8  0x08184cd4 in lazy_vacuum_index (indrel=0x99b4dcf0, stats=0x99a023e0,    vacrelstats=0x99a012e0) at
vacuumlazy.c:938
#9  0x081854b6 in lazy_vacuum_rel (onerel=0x99b47650, vacstmt=0x99b059d0,    bstrategy=0x99a07018,
scanned_all=0xbfbfcfd8"") at vacuumlazy.c:762
 
#10 0x08184265 in vacuum_rel (relid=16424, vacstmt=0x99b059d0,    do_toast=1 '\001', for_wraparound=0 '\0',
scanned_all=0xbfbfcfd8"")   at vacuum.c:978
 
#11 0x081845ea in vacuum (vacstmt=0x99b059d0, relid=0, do_toast=1 '\001',    bstrategy=0x0, for_wraparound=0 '\0',
isTopLevel=1'\001') at vacuum.c:230
 
#12 0xbbab50c3 in pgss_ProcessUtility (parsetree=0x99b059d0,    queryString=0x99b05018 "vacuum (verbose,analyze)
pgfs.dirent;",   params=0x0, isTopLevel=1 '\001', dest=0x99b05b80,    completionTag=0xbfbfd21a "") at
pg_stat_statements.c:603
#13 0x082499ea in PortalRunUtility (portal=0x99b33018, utilityStmt=0x99b059d0,    isTopLevel=1 '\001', dest=0x99b05b80,
completionTag=0xbfbfd21a"")   at pquery.c:1191
 
#14 0x0824a79e in PortalRunMulti (portal=0x99b33018, isTopLevel=4 '\004',    dest=0x99b05b80, altdest=0x99b05b80,
completionTag=0xbfbfd21a"")   at pquery.c:1298
 
#15 0x0824b21a in PortalRun (portal=0x99b33018, count=2147483647,    isTopLevel=1 '\001', dest=0x99b05b80,
altdest=0x99b05b80,   completionTag=0xbfbfd21a "") at pquery.c:822
 
#16 0x08247dc7 in exec_simple_query (   query_string=0x99b05018 "vacuum (verbose,analyze) pgfs.dirent;")   at
postgres.c:1059
#17 0x08248a79 in PostgresMain (argc=2, argv=0xbb912650,    username=0xbb9125c0 "takashi") at postgres.c:3943
#18 0x0820e231 in ServerLoop () at postmaster.c:3590
#19 0x0820ef88 in PostmasterMain (argc=3, argv=0xbfbfe59c) at postmaster.c:1110
#20 0x081b6439 in main (argc=3, argv=0xbfbfe59c) at main.c:199
(gdb) list
1830                                                     offsetof(PREDICATELOCK, xactLink));
1831    
1832                    oldlocktag = predlock->tag;
1833                    Assert(oldlocktag.myXact == sxact);
1834                    oldtarget = oldlocktag.myTarget;
1835                    oldtargettag = oldtarget->tag;
1836    
1837                    if (TargetTagIsCoveredBy(oldtargettag, *newtargettag))
1838                    {
1839                            uint32          oldtargettaghash;
(gdb)

pgsql-hackers by date:

Previous
From: carl clemens
Date:
Subject: default_tablespace
Next
From: Rémi Zara
Date:
Subject: Re: pika failing since the per-column collation patch