Обсуждение: Corrupted index file after restoring WAL on warm spare server
Recently I went through the steps to refresh the database (8.3.4) on my development server (running Fedora Core 5 Linux),
making a tarball of the live database, then restoring it on the development server, and running all the archived WAL files.
Everything worked fine as far as I can tell, I don't see any errors in any of my logs.
Howevever, when I go to access one table, the index appears to be corrupted because the record I get for one query doesn't match the record key I give.
The search works correctly on the live server.
Reindexing that table on the warm spare system fixes the problem.
I redid setting up the warm spare server a second time to see if it was a one-time anomaly, but I have the exact same condition again.
What could be causing this? If this is a bug, what can I do to help track it down?
--
Mike Nolan
htfoot@gmail.com
making a tarball of the live database, then restoring it on the development server, and running all the archived WAL files.
Everything worked fine as far as I can tell, I don't see any errors in any of my logs.
Howevever, when I go to access one table, the index appears to be corrupted because the record I get for one query doesn't match the record key I give.
The search works correctly on the live server.
Reindexing that table on the warm spare system fixes the problem.
I redid setting up the warm spare server a second time to see if it was a one-time anomaly, but I have the exact same condition again.
What could be causing this? If this is a bug, what can I do to help track it down?
--
Mike Nolan
htfoot@gmail.com
Sorry, I meant 8.2.4 (darn typo virus)
On 5/24/07, Michael Nolan <htfoot@gmail.com> wrote:
Recently I went through the steps to refresh the database (8.3.4) on my development server (running Fedora Core 5 Linux),
making a tarball of the live database, then restoring it on the development server, and running all the archived WAL files.
Everything worked fine as far as I can tell, I don't see any errors in any of my logs.
Howevever, when I go to access one table, the index appears to be corrupted because the record I get for one query doesn't match the record key I give.
The search works correctly on the live server.
Reindexing that table on the warm spare system fixes the problem.
I redid setting up the warm spare server a second time to see if it was a one-time anomaly, but I have the exact same condition again.
What could be causing this? If this is a bug, what can I do to help track it down?
--
Mike Nolan
htfoot@gmail.com
"Michael Nolan" <htfoot@gmail.com> writes:
> Howevever, when I go to access one table, the index appears to be corrupted
> because the record I get for one query doesn't match the record key I give.
> Reindexing that table on the warm spare system fixes the problem.
> I redid setting up the warm spare server a second time to see if it was a
> one-time anomaly, but I have the exact same condition again.
> What could be causing this? If this is a bug, what can I do to help track
> it down?
It sounds like you have a reproducible test case --- can you make it
available to someone else?
regards, tom lane
On 5/24/07, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Not very easily, Tom. The tarball files are around 35 GB (uncompressed) and I assume they'd only work on a fairly similar system anyway.
It sounds like you have a reproducible test case --- can you make it
available to someone else?
I assume shell level access would be needed. I may be able to set up a way to get to someone through the firewall, but there are some security issues I'd have to clear with our Executive Director, since there's quite a bit of confidential information in the database and elsewhere on the server.
Is this something where I could call someone and have them walk me through checking things?
I tried the same thing on a 3rd server (similar hardware and same O/S), and the query is working correctly there. I'm not sure what that tells me.
--
Mike Nolan