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's postgres-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.
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
