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.
>
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 |