Re: [HACKERS] Statement-level rollback

On Mon, Jun 18, 2018 at 4:51 PM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
> On 2018-Jun-16, Robert Haas wrote:
>> I'm not sure that really solves the problem, because changing the GUC
>> in either direction causes the system to behave differently.  I don't
>> see any particular reason to believe that changing the behavior from A
>> to B is any more or less likely to break applications than a change
>> from B to A.
>
> I suppose the other option is to just disallow a change during a running
> session completely.  That is, whatever value is has when you connect is
> final.
>
> Maybe a better idea is to make write-once: the application connects,
> establishes its desired behavior, and then it cannot be changed anymore.

That sounds even worse.  I think if we're going to have this behavior
at all, it should be possible to change the setting.

>> I put this feature, which - in this interest of full disclosure - is
>> already implemented in Advanced Server and has been for many years,
>> more or less in the same category as a hypothetical GUC that changes
>> case-folding from lower case to upper case.  That is, it's really nice
>> for compatibility, but you can't get around the fact that every bit of
>> software that is supposed to run on all PostgreSQL instances has to be
>> tested in all possible modes, because otherwise you might find that it
>> doesn't work in all of those modes, or doesn't work as expected.  It
>> is a behavior-changing GUC par excellence.
>
> Thanks for bringing this up.
>
> While I agree that both your example and the feature being proposed are
> behavior-changing, I don't think the parallel is very good, because the
> level of effort in order to port from one behavior to the other is much
> higher with statement-scoped rollback than with case-folding.  In the
> case-folding example, I don't think you need to audit/rewrite all your
> applications in order to make them work: most of the time just rename a
> few tables, or if not just add a few quotes (and you can probably do it
> programatically.)
>
> With statement-scope rollback what you face is a more thorough review ..
> probably adding a savepoint call every other line.  I'm not sure that
> for a large codebase this is even reasonable to start talking about.

Yeah.  The real problem is what happens when two code bases collide.
For example, suppose you have a large code base that is using this,
and then you install some extensions that weren't tested with it
enabled.  Or, you install a tool like pgAdmin or pgpool or whatever
that turns out not to understand the new mode, and stuff breaks.  It's
a distributed burden on the ecosystem.  I don't think we can avoid
that.  It's just a matter of whether it is worth it or not.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company