Re: Worries about delayed-commit semantics

PFC wrote:
> On Fri, 22 Jun 2007 16:43:00 +0200, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>> Simon Riggs wrote:
>>> On Fri, 2007-06-22 at 14:29 +0100, Gregory Stark wrote:
>>> > "Joshua D. Drake" <jd(at)commandprompt(dot)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")

I think you got the last line backwards - without the fsync() after
a commit, you can't be sure that the data made it into the controller
cache. To be safe you *always* need the fsync() - but it will probably
be much cheaper if your controller doesn't have to actually write to
the disks, but can cache in battery-backed ram instead. Therefore,
if you own such a controller, you probably don't need deferred commits.

BTW, I like synchronous_commit too - but maybe asynchronous_commit
would be even better, with inverted semantics of course.
The you'd have "asynchronous_commit = off" as default.