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