>
> > For now, though, I don't mind living with my simple
> > hack if indeed it simply means I risk losing a transaction
> > during a crash. Or, actually, have simply increased that risk
> > (the sequence flush/log id/CRASH is possible, after all).
> >
> No. This is why Vadim wants the second flush. If the machine
> crashes like you describe the client will not be told "transaction
> committed". The problem is when a client is told something,
> that is not true after a crash, which can happen if the second
> flush is left out.
But commercial db's do that. They return 'done' for every query, while
they write they log files ever X seconds. We need to allow this. No
reason to be more reliable than commercial db's by default. Or, at
least we need to give them the option because the speed advantage is
huge.
> > I'm a lot more comfortable with this than with the potential
> > damage done during a crash when fsync'ing both log file and
> > data is disabled, when the log can then be written by the
> > system followed by a crash before the data tuples make it
> > to disk.
> >
> Yes, this is a much better situation.
-- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026