From: stef <stef@ummon.com>
To: Eric Lauzon <eric.lauzon@abovesecurity.com>
Cc: Richard Huxton <dev@archonet.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: Database possible corruption , unsolvable mystery
Date: Wed, 29 Mar 2006 17:52:55 -0500
Message-ID: <442B0FC7.4040303@ummon.com> (raw)
In-Reply-To: <F7B73864DD39FA40B6C56B3CE0D4D1CBF007C1@asdc003.abovesecurite.lan>
References: <F7B73864DD39FA40B6C56B3CE0D4D1CBF007C1@asdc003.abovesecurite.lan>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: stef@ummon.com, eric.lauzon@abovesecurity.com, dev@archonet.com
Subject: Re: Database possible corruption , unsolvable mystery
In-Reply-To: <442B0FC7.4040303@ummon.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox