Excerpts from Nikhil Sontakke's message of mié mar 16 08:51:00 -0300 2011:
> Hi,
>
> > 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 -
Hi,
> Of course, as you mentioned earlier, it's not impossible
> there's a bug in the recovery code.
Yeah, I was looking at the repair_frag function in 8.3.13 (yup it's
ugly!) and found out that the normal ExecInsertIndexTuples call is
used to insert the index entries. That is standard index code
On Wed, Mar 16, 2011 at 7:51 AM, Nikhil Sontakke
wrote:
> Hi,
>
>> 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 -> ...
>>
>>> Was there a
Hi,
> 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 -> ...
>
>> Was there a machine restart in the picture as well?
>
It seems there might ha
Hi Daniel,
>
> I have also, coincidentally, encountered corruption of a system
> catalog index -- 8.3.11 -- I have saved the file for forensics. Is it
> possible that I also receive a copy of this program?
>
Will it be possible for you to share the file/logs off-list with me? I
can also try to d
>> 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.
>>
>
> So do you have logs from the server when it was restarted? It should
> say how far it recovered before it started up
>
Unfortunate
On Sat, Mar 12, 2011 at 3:06 AM, Nikhil Sontakke
wrote:
> 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.
>
So do you have logs from the server when it was restarted? It should
say how far
On Wed, Mar 9, 2011 at 6:02 AM, Alvaro Herrera
wrote:
> I'll send you a perl program we wrote for a customer to check for
> strange issues in btrees. Please give it a spin; it may give you more
> clues. If you find additional checks to add, please let me know!
I have also, coincidentally, encou
>> 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
On Fri, Mar 11, 2011 at 2:28 PM, Nikhil Sontakke
wrote:
>> I'm not sure, but I doubt it. If the VACUUM FULL committed, then the
>> WAL records should be on disk, but if the immediate shutdown happened
>> while it was still running, then the WAL records might still be in
>> wal_buffers, in which c
>>> VACUUM FULL - immediate shutdown - problem with recovery?
>
> An immediate shutdown == an intentional crash. OK, so you have the
> VACUUM FULL and the immediate shutdown just afterward. So we just
> need to figure out what happened during recovery.
>
Right.
>> But WAL replay should still ha
On Fri, Mar 11, 2011 at 6:17 AM, Nikhil Sontakke
wrote:
>> VACUUM FULL - immediate shutdown - problem with recovery?
An immediate shutdown == an intentional crash. OK, so you have the
VACUUM FULL and the immediate shutdown just afterward. So we just
need to figure out what happened during recov
Hi,
>>> 1. Somebody inserts a bunch of new tuples into the relation, causing
>>> growth in the index.
>>
>> In case it's not obvious VACUUM FULL would do precisely that.
>
> Oh, I didn't even think about that. Yeah, that could be it, too.
Thanks a lot Greg and Robert. This theory seems very plau
On Thu, Mar 10, 2011 at 12:52 PM, Greg Stark wrote:
> On Thu, Mar 10, 2011 at 1:45 PM, Robert Haas wrote:
>> 1. Somebody inserts a bunch of new tuples into the relation, causing
>> growth in the index.
>
> In case it's not obvious VACUUM FULL would do precisely that.
Oh, I didn't even think abou
On Thu, Mar 10, 2011 at 1:45 PM, Robert Haas wrote:
> 1. Somebody inserts a bunch of new tuples into the relation, causing
> growth in the index.
In case it's not obvious VACUUM FULL would do precisely that.
> 2. Before the blocks are written to disk, system crash.
> 3. pg_resetxlog
Do you have
On Wed, Mar 9, 2011 at 7:14 PM, Greg Stark wrote:
> On Wed, Mar 9, 2011 at 11:28 PM, Nikhil Sontakke
> wrote:
>> "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. A
Hi,
>> "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
Excerpts from Nikhil Sontakke's message of mié mar 09 20:28:19 -0300 2011:
> While I rummage around the code more, does anyone have any theories on
> the below?
>
> "Other peculiarity in the index file is that we found a lot of zeroed
> out pages. Blocks from #279 to #518 are all completely zeroe
>
> What does stat say for the index data file? Are the Size and Blocks
> values the same (modulo block size)? Or are these blocks actually not
> allocated?
>
stat 58401
File: `58401'
Size: 4300800 Blocks: 8400 IO Block: 4096 regular file
Device: 801h/2049d Inode: 13901264
On Wed, Mar 9, 2011 at 11:28 PM, Nikhil Sontakke
wrote:
> "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? Ap
Hi,
>>> Blocks 519 to 521 are DELETED. They do not have the LEAF flag set,
>>> meaning they could be internal pages, but that is strange since ROOT
>>> page is at level 1. Also importantly their next XID is set FrozenXid,
>>> meaning VACUUM FULL was at play. Maybe due to deletes, we reduced the
>>
>> Ouch. Attempting to attach the dotty image again..
>
> I don't understand this graph. What are the arrows? Downlinks or
> sibling pointers?
>
Sorry, they are sibling previous and next pointers. The ROOT is at
level 1, rest all live blocks are at level 0. #524 is the leftmost
page.
Regards,
N
Excerpts from Nikhil Sontakke's message of mié mar 09 11:16:22 -0300 2011:
> >> Re-sending without the attachments. Can someone please allow my
> >> attachments through from the previous email?
> >
> > They are not in the moderation queue, so presumably they got eaten by
> > the antispam grue.
>
>
Excerpts from Nikhil Sontakke's message of mié mar 09 10:51:50 -0300 2011:
> Re-sending without the attachments. Can someone please allow my
> attachments through from the previous email?
They are not in the moderation queue, so presumably they got eaten by
the antispam grue.
> Blocks 519 to 521
Re-sending without the attachments. Can someone please allow my
attachments through from the previous email?
TIA
Nikhils
-- Forwarded message --
From: Nikhil Sontakke
Date: Wed, Mar 9, 2011 at 8:42 PM
Subject: index corruption in PG 8.3.13
To: pgsql-hackers@postgresql.org
Hi,
25 matches
Mail list logo
