Re: another pg database corruption? - Mailing list pgsql-admin

Andrew Sullivan wrote:

> On Tue, Oct 28, 2003 at 03:12:37PM +0100, pginfo wrote:
> > >
> >
> > I do not have made any patchin on my kernel.I used the standart reiserfs
> > with my linux distro.
>
> Yes, but have you kept up to date with new kernel releases from Red
> Hat?

Realy no.But I have many instalations with this version and the same config. And
all this is working well for long periode.
The problem is that the corrupted was the biggest one.

>  They're pretty good about releasing patched kernels if there is
> a problem.
>
> > > your disk.  Note that to produce useful results, you may have to do
> > > the destructive tests.  You'll be wanting to back up your data first.
> >
> > I can not:). If I try pg_dump the pg crashes.One of my problems is to
> > restore this data if  possible.
>
> Shut down the database, I'm afraid, and copy the data directory
> before you start doing things.
>

I did it.

> > >From this position I spoke, that I need to be sure that pg is very stable.
>
> So far as I've heard, the cases of clog file corruption have all been
> related to hardware.  You'd best think about replacing your disk or
> your controller.

The system was with 3 hdd. One for my application server one for pg and one for
archives.After the first problem I execute initdb -D on my archive disk, got the
last possible backup and start to insert data. All was well, but after 10 h of
work
pg stops ( I sendet this error here).
Also later I tryed to recreate the db on my last disk and this time I had
problems by restoring the data.
So I think I do not have problem with my hdd ( if I do not have problem with all
3 hdd at same time, or with controller).

>  Have you had any crashes lately?  Anything unusual?
> Are you using ECC RAM?  (If not, are you sure you don't have bad RAM?
> If you got a bad bit written at the wrong time, you'd have a real
> mess.)

My rad is 1G ECC each. I am using 2 G of RAM on this box..

>
>
> > Any idea for fixing this data is wellcome. I will check the data
> > inconsistent.
>
> As I understand it, you need to zero out the file with dummy data in
> order to get going again.  You really need to plough the archives for
> what to do, though.  I've never had to do this.
>
> A
>
> --
> ----
> Andrew Sullivan                         204-4141 Yonge Street
> Afilias Canada                        Toronto, Ontario Canada
> <andrew@libertyrms.info>                              M2P 2A8
>                                          +1 416 646 3304 x110
>
> ---------------------------(end of broadcast)---------------------------
> TIP 8: explain analyze is your friend

  reagards,
ivan.