>> "Other peculiarity in the index file is that we found a lot of zeroed
>> out pages. Blocks from #279 to #518 are all completely zeroed out
>> without any signs of even a page header. Any ideas on how we can get
>> so many zeroed out blocks? Apart from the extend code path, I fail to
>> see any other. And this is an unusually large number of zero pages"
> Well, if you see the root block child pointers, they go to pages
> 2, 4-277,522-524. So pages 278 to 521 seem unused for some reason,
> which is rather strange. But apparently only page 523 is zeroed and
> shouldn't be.
Yeah, the very definition of strange all this.
> It seems hard to believe that there would be 245 unsuccessful attempts
> at extending the file.
> Page 522 is suspect too ... why does it have a single item? Note its
> LSN is very close to the one on page 521.
If you look at my png, you will notice that there is a deleted block
chain at play around 522.
Deleted 519's previous points to Deleted 520.
Deleted 520's previous points to Deleted 521.
Deleted 521's previous points to 522
Want to know where the next of all these 4 blocks point to? Block 277.
Another interesting thing is all these Deleted blocks have next XID
set to FroxzenXID. And who sets it to that - only VACUUM FULL. That's
why my suspicions around VF..
In response to
pgsql-hackers by date
|Next:||From: hans wulf||Date: 2011-03-10 12:31:03|
|Subject: Read uncommitted ever possible?|
|Previous:||From: Michael Meskes||Date: 2011-03-10 11:25:01|
|Subject: Re: pgsql: Added new version of ecpg's parser
generator script. This one wa|