> I have to agree with Alfred here: this does not sound like a feature,
> it sounds like a horrid hack. You're giving up *all* consistency
> guarantees for a performance gain that is really going to be pretty
> minimal in the WAL context.
The "buffered log" still guarantees consistency within the database.
The only thing that is a problem, is that the client had his transaction
committed, but the whole transaction may be lost if the machine crashes
hard.
This is a point where a lot of people sit on an impression of false safety.
To actually guarantee that a committed transaction is safe, at least
two separate machines with an independent set of disks on two different
locations with synchronous replication (of at least the log) are needed.
In all other situations there is still a too high risc of loosing committed
transactions.
I have made the experience, that telling your programmers and clients,
that a few of their latest transactions are not guaranteed to be safe leads
to a lot higher robustness overall. There is nothing worse that a false
feeling of safety.
> Earlier, Vadim was talking about arranging to share fsyncs of the WAL
> log file across transactions (after writing your commit record to the
> log, sleep a few milliseconds to see if anyone else fsyncs before you
> do; if not, issue the fsync yourself). That would offer less-than-
> one-fsync-per-transaction performance without giving up any
> guarantees.
> If people feel a compulsion to have a tunable parameter, let 'em tune
> the length of the pre-fsync sleep ...
This is not a solution to the perfomance aspect with the same impact as
"buffered log", since if you tune that time up every commit has to wait longer.
There is a tradeoff between the wait time and the time fsync needs.
Thus we are talking about rather short times in the milliseconds here.
Andreas
