Re: [HACKERS] Statement-level rollback
От | David Steele |
---|---|
Тема | Re: [HACKERS] Statement-level rollback |
Дата | |
Msg-id | dd643238-3a63-6596-034c-8842072a1b12@pgmasters.net обсуждение исходный текст |
Ответ на | Re: [HACKERS] Statement-level rollback ("Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>) |
Ответы |
Re: [HACKERS] Statement-level rollback
Re: [HACKERS] Statement-level rollback |
Список | 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 по дате отправления: