filesystem suggestion for pg - Mailing list pgsql-admin

From pginfo
Subject filesystem suggestion for pg
Date
Msg-id 3FC58ACF.12A27EDF@t1.unisoftbg.com
Whole thread Raw
Responses Re: filesystem suggestion for pg
List pgsql-admin
Hi ,

We are using pg as oracle alternative on ~30 production db servers.
Also we are planing to migrate all oracle servers to pg if we can get
stable config.

After 6 m. of intensive use of systems by diferent customers we do not
know what for filesystem to install.

In this time we are using linux red hat (7.3 or 9.0) with ext3 or
reiserfs.

For 6 m. we have 6 pg crashes and total data loses (it is very bad
result for us).

The last one was today on linux red hat 9.0 and reiserfs after power
down (in most cases the problems are detected after power down).

Only for info I send the log:
LOG:  checkpoint record is at 0/5EF69F40
LOG:  redo record is at 0/5EF69F40; undo record is at 0/0; shutdown
FALSE
LOG:  next transaction id: 165597; next oid: 1931805
LOG:  database system was not properly shut down; automatic recovery in
progress
LOG:  redo starts at 0/5EF69F80
PANIC:  Invalid page header in block 93 of 1919556
LOG:  startup process (pid 1253) was terminated by signal 6
LOG:  aborting startup due to startup process failure


Also for this time we do not have any problems with oracle servers (and
we have had many power downs).

I belive it is not pg bug, but in all cases the only afected data are
this by pg.

So, my question:

We will to continue to use pg on linux, but I will be hapy to find info
about what for filesystem to use (also we can change the linux distro to
debian or suse if needet, but not to freebsd) and what mounting options
to use.

We found that ext3 is less stable comparing to reiserfs and we need to
use fsck.
We are using ~300 tables with ~3M rows (max) .
Also we are using mostly dual pentium + IDE disks.

regards,
ivan.


pgsql-admin by date:

Previous
From: "Rudi Starcevic"
Date:
Subject: Re: pg_lo_import alternative ...
Next
From: "Andrei Bintintan"
Date:
Subject: Re: pg_lo_import alternative ...