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