Tom Lane wrote:
I've been reflecting a bit about whether the notion of deferred fsync
for transaction commits is really safe. The proposed patch tries to
ensure that no consequences of a committed transaction can reach disk
before the commit WAL record is fsync'd, but ISTM there are potential
holes in what it's doing. In particular the path that concerns me is
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
Ahh but it can. :). PostgreSQL can guarantee that "if" the hardware is
not faulty and the OS does what it is supposed to do... etc..
And yes, it is marketing but life is marketing, getting girlfriends is
marketing. What matters is that once the marketing is over, you can
stand up to the hype.
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.
Joshua D. Drake
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
