Marc G. Fournier wrote:
> >>>> Just to expand on the 'dubiousness' ... remember awhile back when I worked
> >>>> through the 'no-WAL' version of PostgreSQL to test loading a database with
> >>>> WAL disabled? The performance improvements on loading a database weren't
> >>>> enough, I seem to recall, to warrant getting rid of WAL altogether ... so
> >>>> I can't see 'delayed WAL' being faster then 'no WAL' ...
> >>>
> >>> Uh, you mean fsync isn't a performance hit as it once was?
> >>
> >> No, I mean that writing WAL doesn't appear to be a performance hit ...
> >> removing WAL writing and doing a large db load, the load is a bit faster,
> >> but not as big as one would hope ...
> >
> > OK. My idea is to remove fsync (poorly named) and add a new parameter
> > called transaction_loss. It would specify the number of seconds or
> > milliseconds before an abrupt server restart that you were willing to
> > lose transactions. The default would be zero (no loss), and we can
> > support -1 for the same as fsync off. Positive values would delay WAL
> > write/fsync for that many seconds/milliseconds.
>
> 'k, right now we have a seperate variable for wal_fsync vs regular fsync
> ... are you looking at merging them into one? Or leaving them as being
> treated seperately?
I was going to leave wal_fsync alone because it controls the method of
fsync, not the frequency of fsync. We could call it
wal_transaction_loss to clarify what it controls. I am also thinking we
should make -1 fsync enough so it maintains a consistent database, and
not even allow the behavior we have now with fsync=off where the
database is left inconsistent after and OS crash. I will have to run
some tests but I bet that fsync to maintain consistency would provide
similar performance to fsync=off, but with the benefit of returing a
consistent database.
> One question, more directed to Tom here ... since they are seperate right
> now, if WAL is fsync, and "regular writing" is no-fsync, doesn't that
> potentially open us up to some *serious* problems? WAL sees the
> transaction as complete, but the write for the rest of the system hasn't
> happened yet?
"regular writing"? Are you talking about the fsync we do from the
background writer (in 8.0) during checkpoint? That has to be done to
maintain consistency no matter what delay they choose.
--
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
