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?



      === 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

Donate to the PostgreSQL Project:
PostgreSQL Replication:

---------------------------(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

Reply via email to