Re: Worries about delayed-commit semantics

On Fri, 22 Jun 2007 16:43:00 +0200, Bruce Momjian <bruce@momjian.us> wrote:

> Simon Riggs wrote:
>> On Fri, 2007-06-22 at 14:29 +0100, Gregory Stark wrote:
>> > "Joshua D. Drake" <jd@commandprompt.com> writes:
>> >
>> > > Tom Lane wrote:
>> > >
>> > >> untrustworthy disk hardware, for instance.  I'd much rather use
>> names
>> > >> derived from "deferred commit" or "delayed commit" or some such.
>> > >
>> > > Honestly, I prefer these names as well as it seems directly related
>> versus
>> > > transaction guarantee which sounds to be more like us saying, if we
>> turn it off
>> > > our transactions are bogus.
>>
>> That was the intention..., but name change accepted.
>>
>> > Hm, another possibility: "synchronous_commit = off"
>>
>> Ooo, I like that. Any other takers?
>
> Yea, I like that too but I am now realizing that we are not really
> deferring or delaying the "COMMIT" command but rather the recovery of
> the commit.  GUC as full_commit_recovery?
>
commit_waits_for_fsync =
force_yes    : makes all commits "hard"yes    : commits are "hard" unless specified otherwise [default]no    : commits
are"soft" unless specified otherwise [should replace   
fsync=off use case]force_no    : makes all commits "soft" (controller with write cache
"emulator")
the force_yes and force_no are for benchmarking purposes mostly, ie. once
your app is tuned to specify which commits have to be guaranteed ("hard")
and which don't ("soft") you can then bench it with force_yes and force_no
to see how much you gained, and how much you'd gain by buying a write
cache controller...