Re: Statement-level rollback

From: Greg Stark <stark(at)mit(dot)edu>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, 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: 2019-01-31 16:01:33
Message-ID: CAM-w4HO=_n+SoOV6yo3hW09LuyW4XVidHpitru5h9B7GevYJ3g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri 7 Dec 2018, 21:43 Robert Haas <robertmhaas(at)gmail(dot)com wrote:

> On Fri, Dec 7, 2018 at 3:34 PM Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
> wrote:
> > Yeah, I agree that this downside is real. I think our only protection
> > against that is to say "don't do that". Like any other tool, it has
> > upsides and downsides; we shouldn't keep it away from users only because
> > they might misuse it.
>
> I have a hard time arguing against that given that EDB has this thing
> in our bag of tricks, but if it weren't for that I'd be fighting
> against this tooth and nail. Behavior-changing GUCs suuuuck.
>

This looks like repeating the autocommit mistakes of the past.

And based on that experience wouldn't the replacement approach be to do
this client side? If libpq had a library option to wrap every statement in
a subtransaction by adding begin/end then this problem would be completely
sidestepped.

>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Banck 2019-01-31 16:09:09 Re: Installation instructions update (pg_ctl)
Previous Message Alvaro Herrera 2019-01-31 15:54:58 Re: MERGE SQL statement for PG12