Re: [HACKERS] Statement-level rollback

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, MauMau <maumau307(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] Statement-level rollback
Date: 2018-06-18 20:51:50
Message-ID: 20180618205150.oikgucexnqzet2zw@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-jdbc

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2018-06-18 20:57:08 Re: [HACKERS] Statement-level rollback
Previous Message Andres Freund 2018-06-18 20:47:41 Re: WAL prefetch

Browse pgsql-jdbc by date

  From Date Subject
Next Message Robert Haas 2018-06-18 20:57:08 Re: [HACKERS] Statement-level rollback
Previous Message Simon Riggs 2018-06-16 10:26:52 Re: [HACKERS] Statement-level rollback