PFC wrote:
On Fri, 22 Jun 2007 16:43:00 +0200, Bruce Momjian <[EMAIL PROTECTED]> wrote:
Simon Riggs wrote:
On Fri, 2007-06-22 at 14:29 +0100, Gregory Stark wrote:
> "Joshua D. Drake" <[EMAIL PROTECTED]> 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.
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
