Re: Statement-level rollback - Mailing list pgsql-hackers

From Greg Stark
Subject Re: Statement-level rollback
Date
Msg-id CAM-w4HO=_n+SoOV6yo3hW09LuyW4XVidHpitru5h9B7GevYJ3g@mail.gmail.com
Whole thread Raw
In response to Re: Statement-level rollback  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Statement-level rollback  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers


On Fri 7 Dec 2018, 21:43 Robert Haas <robertmhaas@gmail.com wrote:
On Fri, Dec 7, 2018 at 3:34 PM Alvaro Herrera <alvherre@2ndquadrant.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.

pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: MERGE SQL statement for PG12
Next
From: Michael Banck
Date:
Subject: Re: Installation instructions update (pg_ctl)