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")
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...
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
