Re: Worries about delayed-commit semantics

["Simon Riggs" <simon(at)2ndquadrant(dot)com>]

On Thu, 2007-06-21 at 18:15 -0400, Tom Lane wrote:

> BTW: I really dislike the name "transaction guarantee" for the
> feature; it sounds like marketing-speak, not to mention overpromising
> what we can deliver. 

There is no marketing speak there, nor any overpromising of what is
delivered. I really don't know where you get that idea.

The patch says exactly what it does: it reduces the level of guarantee
provided by a transaction commit and thereby causes almost-certain data
loss in the event of a crash, for transactions that have used the
feature. How can 'you get less' be an overpromise? 

So the purpose of the name was to be explicit about the loss of
robustness that is being traded for performance. If I'd wanted to give
it a marketing name, it would be called 'fast commit'.

>  Postgres can't "guarantee" anything in the face of
> untrustworthy disk hardware, for instance.  

The "guarantee" PostgreSQL currently offers is the ACID durability
guarantee. Postgres has for many years differentiated itself from MySQL
on the basis of the certainty of the commit action.

True, disk hardware can nullify the commit guarantee.

> I'd much rather use names
> derived from "deferred commit" or "delayed commit" or some such.

I'm happy with various names and even had a specific post on the
subject.

Deferred Commit is the best description of the feature to me, but
doesn't highlight the dangers of using it. Am I being too cautious?
Would users understand that "deferred commit" would cause data loss? If
yes, then I'm perfectly happy with that name.

No feedback means name change to deferred commit.

-- 
  Simon Riggs             
  EnterpriseDB   http://www.enterprisedb.com