Re: Statement-level rollback

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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: 2018-12-07 20:59:42
Message-ID: 22389.1544216382@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> 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.

Uh, we're not seriously considering a GUC that changes transactional
behavior are we? I thought we learned our lesson about that from the
autocommit fiasco. I'm not quite going to say "that'll go in over my
dead body", but I *urgently* recommend finding a less fragile way
to do it.

In a quick look at the patch, it seems that it has a BEGIN/START
TRANSACTION option, which perhaps would do for the "less fragile"
way; the problem is that it's also adding a GUC. Maybe we could
make the GUC read-only, so that it's only a reporting mechanism
not a twiddlable knob? (BTW, if it's not GUC_REPORT, you are
missing a large bet; that would at least make it *possible* for
clients to not be broken by this, even if it would still be an
unreasonable amount of work for them to cope with it.)

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-12-07 21:02:53 Re: Statement-level rollback
Previous Message Joshua D. Drake 2018-12-07 20:56:01 Re: Statement-level rollback