Обсуждение: Database corruption with Postgre 7.4.2 on FreeBSD 6.1?

Поиск
Список
Период
Сортировка

Database corruption with Postgre 7.4.2 on FreeBSD 6.1?

От
aurora
Дата:
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

Re: Database corruption with Postgre 7.4.2 on FreeBSD 6.1?

От
"Shoaib Mir"
Дата:
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)

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




Re: Database corruption with Postgre 7.4.2 on FreeBSD 6.1?

От
aurora
Дата:
 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,
>



Re: Database corruption with Postgre 7.4.2 on FreeBSD 6.1?

От
"Aaron Glenn"
Дата:
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

Re: Database corruption with Postgre 7.4.2 on FreeBSD 6.1?

От
"Shoaib Mir"
Дата:
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)


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?

               http://archives.postgresql.org