Re: Statement-level rollback

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, 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 21:09:31
Message-ID: 20181207210931.jm63m4gmq5hgwm75@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2018-12-07 16:02:53 -0500, Tom Lane wrote:
> Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> > 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?
>
> Yeah, but there is also lots of demand for stability in basic
> transactional semantics. I refer you again to the AUTOCOMMIT business;
> there were a lot of claims that that wouldn't break too much, and they
> were all wrong.

I think it could partially be addressed by not allowing to set it on the
commandline, server config, etc. So the user would have to set it on a
per-connection basis, potentially via the connection string.

I'm quite concerned how this'll make it much harder to write UDFs that
work correctly. If suddenly the error handling expected doesn't work
anymore - because they an error just skips over a statements - a lot of
things will break in hard to understand ways.

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2018-12-07 21:17:47 Thinking about EXPLAIN ALTER TABLE
Previous Message Tom Lane 2018-12-07 21:02:53 Re: Statement-level rollback