Skip site navigation (1) Skip section navigation (2)

Re: Database possible corruption , unsolvable mystery

From: stef <stef(at)ummon(dot)com>
To: Eric Lauzon <eric(dot)lauzon(at)abovesecurity(dot)com>
Cc: Richard Huxton <dev(at)archonet(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Database possible corruption , unsolvable mystery
Date: 2006-03-29 22:52:55
Message-ID: 442B0FC7.4040303@ummon.com (view raw or flat)
Thread:
Lists: pgsql-performance
Eric Lauzon wrote:

>Mabey later if this dosen't fix the problem , and as of information its
>7.4.6 [i know its not the most rescent]
>but it is the way it is right now and we suspect the problem might have
>come from a power outage while there was
>a full vacuum and the reason why its only one table that has been
>affected is probably because it was the table being vacummed,
>but this is only an assumption right now and more info will folow if the
>problems persis after a full restore.
>
>  
>
Hrm, you know that you -should- upgrade to at least the latest 7.4 
(7.4.13 I think is the most recent). looking from the changelogs, there 
are a few bugs that you could be hitting;

7.4.10
    * Fix race condition in transaction log management There was a 
narrow window in which an I/O operation could be initiated for the wrong 
page, leading to an Assert failure or data corruption.

7.4.9
    * Improve checking for partially-written WAL pages
    * Fix error that allowed VACUUM to remove ctid chains too soon, and 
add more checking in code that follows ctid links. This fixes a 
long-standing problem that could cause crashes in very rare circumstances.

7.4.8
    * Repair race condition between relation extension and VACUUMThis 
could theoretically have caused loss of a page's worth of 
freshly-inserted data, although the scenario seems of very low 
probability. There are no known cases of it having caused more than an 
Assert failure

    and these are only the ones that appear 'notably' in the changelog. 
In short, I -really- -would- -strongly- -advise- you upgrading to 
7.4.13. Personally, I would have made this my first step, especially if 
your data is important.

    There is no need for a dump/reload between minor point releases. 
Although there is a security fix in 7.4.8.

    Since the db is in a state of 'down' or repair, why not do it now ? 
two birds, one stone.

    Regards
    Stef

In response to

pgsql-performance by date

Next:From: Eric LauzonDate: 2006-03-29 23:33:21
Subject: Re: Database possible corruption , unsolvable mystery
Previous:From: Eric LauzonDate: 2006-03-29 22:31:17
Subject: Re: Database possible corruption , unsolvable mystery

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group