Re: [HACKERS] Index corruption - Mailing list pgsql-hackers

From Adriaan Joubert
Subject Re: [HACKERS] Index corruption
Date
Msg-id 386A1457.432DCE8E@albourne.com
Whole thread Raw
In response to Index corruption  (Adriaan Joubert <a.joubert@albourne.com>)
Responses Re: [HACKERS] Index corruption
List pgsql-hackers
Further to my problem: I've run the vacuum in a backend under the debugger and
at least figured out in which
loop the zillions of files are created. It is in md.c. In the stack trace
below, you can see that blockno has got a totally stupid value and in the loop
in lines 1049-1063 in md.c (v 6.5.3. sources) it opens zillions of files. If
anybody knows where this comes from I'd appreciate it. In the meantime I'll
try to dig a bit further.

Cheers,

Adriaan


>0  0x12012d8d4 in _mdfd_getseg(reln=0x1402488c0, blkno=745239393) "md.c":1051

#1  0x12012c7a8 in mdread(reln=0x1402488c0, blocknum=745239393,
buffer=0x14012ec70="\334") "md.c":414
#2  0x12012ddfc in smgrread(which=0, reln=0x1402488c0, blocknum=745239393,
buffer=0x14012ec70="\334") "smgr.c":226
#3  0x12011b724 in ReadBufferWithBufferLock(reln=0x1402488c0,
blockNum=745239393, bufferLockHeld='\000') "bufmgr.c":302
#4  0x12011b4c0 in ReadBuffer(reln=0x1402488c0, blockNum=745239393)
"bufmgr.c":180
#5  0x120063ce8 in _bt_getbuf(rel=0x1402488c0, blkno=745239393, access=1)
"nbtpage.c":304
#6  0x120069950 in _bt_step(scan=0x14025ca68, bufP=0x11fffb6c8,
dir=ForwardScanDirection) "nbtsearch.c":1131
#7  0x12006867c in _bt_next(scan=0x14025ca68, dir=ForwardScanDirection)
"nbtsearch.c":706
#8  0x120065140 in btgettuple(scan=0x14025ca68, dir=ForwardScanDirection)
"nbtree.c":390
#9  0x12017f238 in fmgr_c(finfo=0x11fffb780, values=0x11fffb7a8,
isNull=0x11fffb778="") "fmgr.c":135
#10 0x12017f81c in fmgr(procedureId=330) "fmgr.c":336
#11 0x120057fa0 in index_getnext(scan=0x14025ca68,
direction=ForwardScanDirection) "indexam.c":316
#12 0x120091714 in vc_vaconeind(vpl=0x11fffba38, indrel=0x1402488c0,
num_tuples=1074, keep_tuples=0) "vacuum.c":2015
#13 0x12008d874 in vc_vacone(relid=1255, analyze='\000', va_cols=0x0)
"vacuum.c":532
#14 0x12008cb80 in vc_vacuum(VacRelP=0x11fffbae8, analyze='\000', va_cols=0x0)
"vacuum.c":267
#15 0x12008c974 in vacuum(vacrel=0x14025b060="", verbose='\001',
analyze='\000', va_spec=0x0) "vacuum.c":150
#16 0x120133b08 in ProcessUtility(parsetree=0x14025b080, dest=Debug)
"utility.c":638
#17 0x120130060 in pg_exec_query_dest(query_string=0x11fffbcc0="vacuum verbose
pg_proc;\n", dest=Debug, aclOverride='\000') "postgres.c":727
#18 0x12012fea8 in pg_exec_query(query_string=0x11fffbcc0="vacuum verbose
pg_proc;\n") "postgres.c":656
#19 0x120131980 in PostgresMain(argc=2, argv=0x11ffffd08, real_argc=2,
real_argv=0x11ffffd08) "postgres.c":1647
#20 0x1200be424 in main(argc=2, argv=0x11ffffd08) "main.c":103
#21 0x12003fb28 in __start(0xb3f, 0x0, 0x2, 0x0, 0x0, 0x1402cc040) in postgres





pgsql-hackers by date:

Previous
From: Tatsuo Ishii
Date:
Subject: PL/pgSQL install procedure
Next
From: Bruce Momjian
Date:
Subject: subquery performance and EXISTS