> So now we're poking a hole in that but we certainly have to ensure that
> any
> transactions that do see the results of our deferred commit themselves
> don't
> record any visible effects until both their commit and ours hit WAL. The
> essential point in Simon's approach that guarantees that is that when you
> fsync you fsync all work that came before you. So committing a
> transaction
> also commits all deferred commits that you might depend on.
>
>> BTW: I really dislike the name "transaction guarantee" for the feature;
>> it sounds like marketing-speak, not to mention overpromising what we
>> can deliver. Postgres can't "guarantee" anything in the face of
>> untrustworthy disk hardware, for instance. I'd much rather use names
>> derived from "deferred commit" or "delayed commit" or some such.
>
> Well from an implementation point of view we're delaying or deferring the
> commit. But from a user's point of view the important thing for them to
> realize is that a committed record could be lost.
>
> Perhaps we should just not come up with a new name and reuse the fsync
> variable. That way users of old installs which have fsync=off silently
> get
> this new behaviour. I'm not sure I like that idea since I use fsync=off
> to run
> cpu overhead tests here. But from a user's point of view it's probably
> the
> "right" thing. This is really what fsync=off should always have been
> doing.
Say you call them SOFT COMMIT and HARD COMMIT...HARD COMMIT fsyncs, obviously.Does SOFT COMMIT fflush() the WAL (so
it'spostgres-crash-safe) or not ?(just in case some user C function misbehaves and crashes)
Do we get a config param to set default_commit_mode=hard or soft ?
By the way InnoDB has a similar option where you set
innodb_flush_log_on_commit (or something). However you cannot set it on a
per-transaction basis. So, on a e-commerce site, for instance, most
transactions will be "unimportant" (ie. no need to fsync, ACI only, like
incrementing products view counts, add to cart, etc) but some transactions
will have to be guaranteed (full ACID) like recording that an order has
been submitted / paid / shipped. But with InnoDB you can't choose this on
a per-transaction basis, so it's all or nothing.