Re: Fwd: index corruption in PG 8.3.13
От | Nikhil Sontakke |
---|---|
Тема | Re: Fwd: index corruption in PG 8.3.13 |
Дата | |
Msg-id | AANLkTim_SK+Ecv8c0ogLYUJu4gkOaMR3wNSG1Bzvd8Dc@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Fwd: index corruption in PG 8.3.13 (Greg Stark <gsstark@mit.edu>) |
Ответы |
Re: Fwd: index corruption in PG 8.3.13
Re: Fwd: index corruption in PG 8.3.13 |
Список | pgsql-hackers |
>> Oh yeah, so if VF committed, the xlog should have been ok too, but >> can't say the same about the shared buffers. > > But there was a later block that *was* written out. What was the LSN > on that block? everything in the WAL log should have been fsynced up > to that point when that buffer was flushed. > Which block are you referring to? After the holes from 279 to 518. We have Deleted 519's (LSN: logid 29, recoff 0xd1fab5bc) previous points to Deleted 520. Deleted 520's (LSN: logid 29, recoff 0xd1fac918) previous points to Deleted 521. Deleted 521's (LSN: logid 29, recoff 0xd1fadc60) previous points to 522 Note that all the above deleted blocks have next xid set to FrozenXid, meaning VF did this. Live 522's (LSN: logid 29, recoff 0xd1fade3c) previous points to the zeroed out 523 block. Note that this seems to be latest LSN in the data file. The next of all these 4 blocks (519 to 522) point to Live Block 277 with (LSN: logid 29, recoff 0xd1fadc60). The ROOT block also has this same LSN. So Blocks 521, 277 and block 3 have this same LSN. The rest of the live blocks appear to have lower LSNs with lower logids. The last block in the index data file, which also seems to be the current left most block, number 524 has an LSN of (logid 29, recoff 0xd1fa97b8) with next sibling set to 523. One interesting observation is that there is another deleted block 278 (again done by VF) with this same LSN and next pointing to 524. And so this must have been the original leftmost block before 524 was promoted to that status. To summarize, as I see it - the zeroed out block 523 should have been the second left-most leaf and should have pointed out to 522. Thus re-establishing the index chain 524 -> 523 -> 522 -> 277 -> ... Phew, I hope the above made some sense and was decipherable. Looking at my png alongside might help a bit more too. Also maybe some bug is indeed hidden in the guts of VF. > Was there a machine restart in the picture as well? I don't think so. Regards, Nikhils
В списке pgsql-hackers по дате отправления: