From: | David Steele <david(at)pgmasters(dot)net> |
---|---|
To: | "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>, 'Tom Lane' <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Statement-level rollback |
Date: | 2017-03-03 16:54:06 |
Message-ID: | dd643238-3a63-6596-034c-8842072a1b12@pgmasters.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-jdbc |
On 3/3/17 2:43 AM, Tsunakawa, Takayuki wrote:
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
>> 1. The argument for this is mostly, if not entirely, "application
>> compatibility". But it won't succeed at providing that if every BEGIN has
>> to be spelled differently than it would be on other DBMSes.
>> Therefore there is going to be enormous pressure to allow enabling the
>> feature through a GUC, or some other environment-level way, and as soon
>> as we do that we've lost.
>
> I thought so, too. I believe people who want to migrate from other DBMSs would set the GUC in postgresql.conf, or with ALTER DATABASE/USER just for applications which are difficult to modify.
>
>> 2. The proposed feature would affect the internal operation of PL functions,
>> so that those would need to become bulletproof against being invoked in
>> either operating environment. Likewise, all sorts of intermediate tools
>> like connection poolers would no doubt be broken if they don't know about
>> this and support both modes. (We would have to start by fixing postgres_fdw
>> and dblink, for instance.)
>
> Yes, I'm going to modify the PL's behavior. I'll also check the dblink and postgres_fdw as well. In addition, I'll have a quick look at the code of pgpool-II and pgBouncer to see how they depend on the transaction state. I'll run the regression tests of contribs, pgpool-II and pgBouncer with default_transaction_rollback_scope set to 'statement'.
>
> But I don't see how badly the statement-level rollback affects those features other than PL. I think the only relevant thing to those client-side programs is whether the transaction is still running, which is returned with ReadyForQuery. Both of statement-level rollback and the traditional behavior leave the transaction running when an SQL statement fails. Server-side autocommit differs in that respect.
Whatever the merits of this patch, it's a pretty major behavioral change
with a large potential impact. Even if what is enumerated here is the
full list (which I doubt), it's pretty big.
Given that this landed on March 28 with no discussion beforehand, I
recommend that we immediately move this patch to the 2017-07 CF.
--
-David
david(at)pgmasters(dot)net
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2017-03-03 17:01:30 | Re: Statement-level rollback |
Previous Message | Masahiko Sawada | 2017-03-03 16:20:44 | Re: Block level parallel vacuum WIP |
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2017-03-03 17:01:30 | Re: Statement-level rollback |
Previous Message | Bogdan Daniliuc | 2017-03-03 09:40:31 | Problem updating driver to 42.0.0 |