Re: Statement-level rollback

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>
Subject: Re: Statement-level rollback
Date: 2018-12-07 20:50:07
Message-ID: 20181207205007.4vfqsn2kup46z25x@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2018-Dec-07, Robert Haas wrote:

> More generally, whether or not we should "keep something away from our
> users" really depends on how likely the upsides are to occur relative
> to the downsides. We don't try to keep users from running DELETE
> because they might delete data they want; that would be nanny-ism.
> But we do try to keep them from reading dirty data from an uncommitted
> transaction because we can't implement that without a risk of server
> crashes, and that's too big a downside to justify the upside. If we
> could do it safely, we might.
>
> From that point of view, this is doubtless not the worst feature
> PostgreSQL will ever have, but it sure ain't the best.

Well, look at this from this point of view: EnterpriseDB implemented
this because of customer demand (presumably). Fujitsu also implemented
this for customers. The pgjdbc driver implemented this for its users.
Now 2ndQuadrant also implemented this, and not out of the goodness of
our hearts. Is there any room to say that there is no customer demand
for this feature?

--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joshua D. Drake 2018-12-07 20:56:01 Re: Statement-level rollback
Previous Message Robert Haas 2018-12-07 20:40:49 Re: Statement-level rollback