Neil Conway wrote:
> Magnus Hagander wrote:
> > Yes, fsync=false is very good for bulk loading *IFF* you can live with
> > data loss in case you get a crash during load.
>
> It's not merely data loss -- you could encounter potentially
> unrecoverable database corruption.
>
> There is a TODO item about allowing the delaying of WAL writes. If we
> maintain the WAL invariant (that is, a WAL record describing a change
> must hit disk before the change itself does) but simply don't flush the
> WAL at transaction commit, we should be able to get better performance
> without the risk of database corruption (so we would need to keep pages
> modified by the committed transaction pinned in memory until the WAL has
> been flushed, which might be done on a periodic basis).
>
> Naturally, there is a risk of losing data in the period between
> transaction commit and syncing the WAL, but no risk of database
> corruption. This seems a reasonable approach to providing better
> performance for people who don't need the strict guarantees provided by
> fsync=true.
Right. Just for clarity, you might lose the last 5 seconds of
transactions, but all transactsions would be completely committed or
aborted in your datbase. Right now with fsync off you can get
transactions partially commited in your database, which is a serious
problem (think moving money from one account to another).
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
