Re: Worries about delayed-commit semantics

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/