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

From David Steele
Subject Re: [HACKERS] Statement-level rollback
Date
Msg-id dd643238-3a63-6596-034c-8842072a1b12@pgmasters.net
Whole thread Raw
In response to Re: [HACKERS] Statement-level rollback  ("Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>)
Responses Re: [HACKERS] Statement-level rollback  (Andres Freund <andres@anarazel.de>)
Re: [HACKERS] Statement-level rollback  ("Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>)
List pgsql-hackers
On 3/3/17 2:43 AM, Tsunakawa, Takayuki wrote:
> From: Tom Lane [mailto:tgl@sss.pgh.pa.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
withALTER 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
havea quick look at the code of pgpool-II and pgBouncer to see how they depend on the transaction state.  I'll run the
regressiontests 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
relevantthing 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
statementfails.  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@pgmasters.net



pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: [HACKERS] Block level parallel vacuum WIP
Next
From: Andres Freund
Date:
Subject: Re: [HACKERS] Statement-level rollback