On Thu, Mar 30, 2006 at 07:24:37PM -0500, Bill Moran wrote: > Kris Kennaway <[EMAIL PROTECTED]> wrote: > > > On Thu, Mar 30, 2006 at 10:49:01PM +0200, [EMAIL PROTECTED] wrote: > > > Kris, > > > > > > > Yes, this is my impression of the problem too. Any time your process > > > > is waiting on disk I/O it is going to perform terribly (on any OS - > > > > disks are slow), and the way to fix this is to make sure it does as > > > > little I/O as possible (by allowing everything to be cached in RAM). > > > > > > just for my curiosity, do you share my opinion on the fsync issue? > > > > Actually I seem to recall that on Linux with default settings fsync() > > lies and does not actually sync data before returning, so maybe it's > > worth turning off on FreeBSD too if you're comfortable with the > > implications of this. > > If you have fsync off and the system crashes, your PostgreSQL database > will probably be corrupt beyond repair. > > I believe the official word from the PostgreSQL folks is that fsync is > safe to turn off if you've got battery-backed cache on your disk > controllers. Many high-end SCSI controllers have this as an option. > > Alternatively, if you're just putting the database on for the first > time, you can temporarily turn fsync off while you're uploading the > data. If the system crashes during this, just delete and recreate > the database and try again. > > It's not generally a good idea to run in production with fsync off, > however, unless you have a battery on your controller.
Yeah..but the thing to remember is that on Linux fsync isn't guaranteeing your data safety anyway, since it's not actually syncing data on disk before returning to the application. Kris
pgpM50X6ixwc2.pgp
Description: PGP signature
