Re: how unsafe (or worst scenarios) when setting fsync OFF for postgresql

Get a SCSI controller with a battery backed cache, and mount the disks
with data=writeback (if you use ext3). If you loose power in the middle
of a transaction, the battery will ensure that the write operation still
completes. With asynch writing setup like this, fsync operations will
return almost immidiately giving you performance close to that of
running with fsync off.

Regards,
Mikael

-----Original Message-----
From: pgsql-performance-owner(at)postgresql(dot)org
[mailto:pgsql-performance-owner(at)postgresql(dot)org] On Behalf Of Guoping
Zhang
Sent: den 27 april 2006 08:31
To: pgsql-performance(at)postgresql(dot)org
Cc: Guoping Zhang (E-mail)
Subject: [PERFORM] how unsafe (or worst scenarios) when setting fsync
OFF for postgresql

Hi,.

We are new to Postgresql. I am appreciated if the following question can
be answered.

Our application has a strict speed requirement for DB operation. Our
tests show that it takes about 10secs for the operation when setting
fsync off, but takes about 70 seconds when setting fsync ON (with other
WAL related parametered tuned).

We have to looking at setting fsync OFF option for performance reason,
our questions are

a) if we set fsync OFF and anything (very low chance though) like OS
crash, loss of power, or hardware fault happened, can postgresql rolls
back to the state that the last checkpoint was done ( but all the
operations after that is lost)

b) Does this roll back to last checkpoint can ensure the database back
to consistent state?

c) What is worst scenarios if setting fsync OFF in term of database
safety. We try to avoid to restore the database from nightly backup.

We view our application is not that data loss critical, say loss of five
minutes of data and operation occasionally, but the database integrity
and consistency must be kept.

Can we set fsync OFF for the performance benefit, have the risk of only
5 minutes data loss or much worse?

Thanks in advance.

Regards,

Guoping

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster