Database corruption with Postgre 7.4.2 on FreeBSD 6.1?
Hello,
We are stressing testing our application. It adds and deletes a lot of
rows. Within 24 hours we ran into some sort of database corruption
problem. We got this error when trying to insert into the users table.
ERROR XX001: invalid page header in block 2552 of relation
"users_name_lower_idx"
The schema looks like this
create table users (
userid integer not null,
name text unique not null,
...
PRIMARY KEY (userid)
);
create index users_name_lower_idx on users (lower(name));
Then the box froze up. We suspect it might ran out of IO bufs.
We are using Postgre 7.4.2 running on FreeBSD 6.1 and Dell 2850.
Thanks for any help,
wy
Try doing a REINDEX and see if you can recover all data blocks as it appears
to me you have some data blocks messed up. If possible try taking the backup
for your database as well.
Thanks,
--
Shoaib Mir
EnterpriseDB (www.enterprisedb.com)
Show quoted text
On 7/27/06, aurora <aurora00@gmail.com> wrote:
Hello,
We are stressing testing our application. It adds and deletes a lot of
rows. Within 24 hours we ran into some sort of database corruption
problem. We got this error when trying to insert into the users table.ERROR XX001: invalid page header in block 2552 of relation
"users_name_lower_idx"The schema looks like this
create table users (
userid integer not null,
name text unique not null,
...
PRIMARY KEY (userid)
);create index users_name_lower_idx on users (lower(name));
Then the box froze up. We suspect it might ran out of IO bufs.
We are using Postgre 7.4.2 running on FreeBSD 6.1 and Dell 2850.
Thanks for any help,
wy
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
From your experience do you expect the database would run into this from
time to time that requires DBA's interventions? Is so it would become a
problem for our customers because our product is a standalone system. We
don't intend to expose the Postgre database underneath.
wy
Show quoted text
Try doing a REINDEX and see if you can recover all data blocks as it
appears
to me you have some data blocks messed up. If possible try taking the
backup
for your database as well.Thanks,
On 7/26/06, aurora <aurora00@gmail.com> wrote:
From your experience do you expect the database would run into this from
time to time that requires DBA's interventions? Is so it would become a
problem for our customers because our product is a standalone system. We
don't intend to expose the Postgre database underneath.wy
Is there a particular reason you're using 7.4.2? At the very least, I
would be using 7.4.13.
regards,
aaron.glenn
It shouldnt run into these problems from time to time, that kind of a
scenario only happened to me once so dont know exactly how often this can
happen. But a recommendation from my end will be to upgrade to the newer
PostgreSQL version as you are using an old release. Also try running some
disk check utlities to see if your hardware is in a good condition.
Thanks,
--
Shoaib Mir
EnterpriseDB (www.enterprisedb.com)
Show quoted text
On 7/27/06, aurora <aurora00@gmail.com> wrote:
From your experience do you expect the database would run into this from
time to time that requires DBA's interventions? Is so it would become a
problem for our customers because our product is a standalone system. We
don't intend to expose the Postgre database underneath.wy
Try doing a REINDEX and see if you can recover all data blocks as it
appears
to me you have some data blocks messed up. If possible try taking the
backup
for your database as well.Thanks,
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?