Re: [HACKERS] Statement-level rollback - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: [HACKERS] Statement-level rollback
Date
Msg-id 20180618205150.oikgucexnqzet2zw@alvherre.pgsql
Whole thread Raw
In response to Re: [HACKERS] Statement-level rollback  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [HACKERS] Statement-level rollback
List pgsql-hackers
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.

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

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: WAL prefetch
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] Statement-level rollback