Re: [HACKERS] Statement-level rollback

On Wed, Nov 1, 2017 at 6:47 AM, MauMau wrote: > From: Simon Riggs > On 14 August 2017 at 23:58, Peter Eisentraut > wrote: >> On 2/28/17 02:39, Tsunakawa, Takayuki wrote: >>> The code for stored functions is not written yet, but I'd like your

Re: [HACKERS] Statement-level rollback

From: Thomas Munro With your v2 patch "make docs" fails. Here is a small patch to apply on top of yours to fix that and some small copy/paste errors, if I understood correctly. Ouch, thanks. I'd like to merge your fix when I submit the next revision of my patch. Regards MauMau -- Sent via

Re: [HACKERS] Statement-level rollback

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Simon Riggs > A backend-based solution is required for PL procedures and functions. > > We could put this as an option into PL/pgSQL, but it seems like it is > a function of the transaction manager

Re: [HACKERS] Statement-level rollback

On 2 November 2017 at 01:33, Peter Eisentraut wrote: > The proposed statement-level rollback feature works in a slightly > different context. It does not change when or how a transaction or > transaction block begins and ends. It only changes what happens

Re: [HACKERS] Statement-level rollback

Tsunakawa>So the statement-level rollback is newer to users, isn't it? Technically speaking, the feature was listed in the changelog. Tsunakawa>Doesn't PgJDBC execute RELEASE after each SQL statement? It does not. Tsunakawa>That said, even with RELEASE, the server memory bloat is not solved.

Re: [HACKERS] Statement-level rollback

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Vladimir > Sitnikov > Tsunakawa> PgJDBC has supported the feature with autosave parameter only > Tsunakawa> recently > > PgJDBC has the implementation for more than a year (REL9.4.1210, 2016-09-07,

Re: [HACKERS] Statement-level rollback

On 2 November 2017 at 13:59, Vladimir Sitnikov wrote: > The performance overhead for "SELECT" statement (no columns, just select) > statement over localhost is 36±4 us vs 38±3 us (savepoint is pipelined along > with user-provided query). That is network overhead is

Re: [HACKERS] Statement-level rollback

Tsunakawa> PgJDBC has supported the feature with autosave parameter only recently PgJDBC has the implementation for more than a year (REL9.4.1210, 2016-09-07, see https://github.com/pgjdbc/pgjdbc/pull/477 ) Tsunakawa> The point raised in this thread was that that creates Tsunakawa> too much

Re: [HACKERS] Statement-level rollback

From: Craig Ringer [mailto:cr...@2ndquadrant.com] > The example often cited is some variant of > > BEGIN; > CREATTE TABLE t2 AS SELECT * FROM t1; > DROP TABLE t1; > ALTER TABLE t2 RENAME TO t1; > COMMIT; > > Right now, we do the right thing here. With default statement level rollback, > you just

Re: [HACKERS] Statement-level rollback

From: Peter Eisentraut [mailto:peter.eisentr...@2ndquadrant.com] > The difference is how error recovery works. So this will necessarily be > tied to how the client code or other surrounding code is structured or what > the driver or framework is doing in the background to manage transactions. >

Re: [HACKERS] Statement-level rollback

On 2 November 2017 at 09:33, Peter Eisentraut wrote: > If you turned the autocommit setting off, then this code would > effectively silently do nothing, and that is obviously quite bad. Right. The example often cited is some variant of BEGIN; CREATTE TABLE t2

Re: [HACKERS] Statement-level rollback

On 10/31/17 13:47, MauMau wrote: > I'm very sorry I couldn't reply to your kind offer. I rebased the > patch and will add it to CF 2017/11. I hope I will complete the patch > in this CF. I've been thinking about this a little bit. Many are worried about repeating the mistakes of the autocommit

Re: [HACKERS] Statement-level rollback

From: Simon Riggs On 14 August 2017 at 23:58, Peter Eisentraut wrote: > On 2/28/17 02:39, Tsunakawa, Takayuki wrote: >> The code for stored functions is not written yet, but I'd like your feedback for the specification and design based on the current patch. I'll

Re: [HACKERS] Statement-level rollback

> On 15 Sep 2017, at 16:19, Daniel Gustafsson wrote: > >> On 01 Sep 2017, at 13:44, Simon Riggs wrote: >> >> On 14 August 2017 at 23:58, Peter Eisentraut >> wrote: >>> On 2/28/17 02:39, Tsunakawa, Takayuki wrote:

Re: [HACKERS] Statement-level rollback

> On 01 Sep 2017, at 13:44, Simon Riggs wrote: > > On 14 August 2017 at 23:58, Peter Eisentraut > wrote: >> On 2/28/17 02:39, Tsunakawa, Takayuki wrote: >>> The code for stored functions is not written yet, but I'd like your >>> feedback

Re: [HACKERS] Statement-level rollback

On 14 August 2017 at 23:58, Peter Eisentraut wrote: > On 2/28/17 02:39, Tsunakawa, Takayuki wrote: >> The code for stored functions is not written yet, but I'd like your feedback >> for the specification and design based on the current patch. I'll add this >>

Re: [HACKERS] Statement-level rollback

On 2/28/17 02:39, Tsunakawa, Takayuki wrote: > The code for stored functions is not written yet, but I'd like your feedback > for the specification and design based on the current patch. I'll add this > patch to CommitFest 2017-3. This patch needs to be rebased for the upcoming commit fest.

Re: [HACKERS] Statement-level rollback

On 1 March 2017 at 16:05, Tom Lane wrote: > Peter Eisentraut writes: >> On 2/28/17 08:17, Tom Lane wrote: >>> I do not really see how this would ever get past the compatibility >>> problems that forced us to give up on server-side autocommit

Re: [HACKERS] Statement-level rollback

Hello, This feature hasn't been updated for a long time, but I've just been interested in this feature and looking into the mailing list. From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us] > In short, you can't make fundamental changes in transactional behavior without > enormous

Re: [HACKERS] Statement-level rollback

There was a mistake in my driver definition, this works fine with autosave=always (but not with autoSave ...) Thanks Again De : Vladimir Sitnikov [via PostgreSQL] Envoyé : mardi 7 mars 2017 22:32:27 À : legrand

Re: [HACKERS] Statement-level rollback

Please disregard my previous message. pgjdbc is already doing upcase conversion, so I would like to see a test case that reproduces the error. Alternatively, could you please capture and share TRACE log? ( https://jdbc.postgresql.org/documentation/head/logging.html#configuration ) Vladimir ср,

Re: [HACKERS] Statement-level rollback

legrand>when usingversion 42.0.0 with legrand> jdbc:postgresql://localhost:5432/postgres?autosave=always The pitfall there is the value should be written with upper case like autosave=ALWAYS. I've filed https://github.com/pgjdbc/pgjdbc/issues/769 to improve that at some point. Vladimir

Re: [HACKERS] Statement-level rollback

Thanks ! that's a very good new ! I'm still receiving the famous "current transaction is aborted" error when usingversion 42.0.0 with jdbc:postgresql://localhost:5432/postgres?autosave=always But I will see that with pgjdbc team ;o) Regards PAscal -- View this message in

Re: [HACKERS] Statement-level rollback

You have to turn it on using the autosave parameter. it's not on by default, and apparently not documented Dave Cramer da...@postgresintl.com www.postgresintl.com On 7 March 2017 at 17:15, legrand legrand wrote: > Thanks ! > > that's a very good new ! > > > I'm

Re: [HACKERS] Statement-level rollback

On 7 March 2017 at 16:18, Michael Banck wrote: > On Tue, Mar 07, 2017 at 01:49:29PM -0700, legrand legrand wrote: > > JDBC has nothing and developers has to play with savepoint as described > > http://blog.endpoint.com/2015/02/postgres-onerrorrollback-explained.html >

Re: [HACKERS] Statement-level rollback

On Tue, Mar 07, 2017 at 01:49:29PM -0700, legrand legrand wrote: > JDBC has nothing and developers has to play with savepoint as described > http://blog.endpoint.com/2015/02/postgres-onerrorrollback-explained.html JDBC has it since 9.4.1210 (2016-09-07), unless I am mistaken:

Re: [HACKERS] Statement-level rollback

Hello, EDB Oracle compatibility proposes edb_stmt_level_tx parameter, psql uses ON_ERROR_ROLLBACK = 'on', ODBC has a parameter for this JDBC has nothing and developers has to play with savepoint as described http://blog.endpoint.com/2015/02/postgres-onerrorrollback-explained.html This feature

Re: [HACKERS] Statement-level rollback

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas > >> Can you provide some references on how other systems provide this feature? > > > > Oracle doesn't. > > Really? Sorry, my sentence was misleading. I meant by "Oracle/MySQL doesn't"

Re: [HACKERS] Statement-level rollback

On Fri, Mar 3, 2017 at 2:15 AM, Tsunakawa, Takayuki wrote: > From: pgsql-hackers-ow...@postgresql.org >> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Peter Eisentraut >> On 2/28/17 02:39, Tsunakawa, Takayuki wrote: >> > I'd like to propose

Re: [HACKERS] Statement-level rollback

From: David Steele [mailto:da...@pgmasters.net] > 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

Re: [HACKERS] Statement-level rollback

On Fri, Mar 3, 2017 at 9:01 AM, Andres Freund wrote: > On 2017-03-03 11:54:06 -0500, David Steele wrote: >> Given that this landed on March 28 with no discussion beforehand, I >> recommend that we immediately move this patch to the 2017-07 CF. > > Seconded. +1 -- Peter

Re: [HACKERS] Statement-level rollback

On 3/3/17 12:01 PM, Andres Freund wrote: > On 2017-03-03 11:54:06 -0500, David Steele wrote: >> Given that this landed on March 28 with no discussion beforehand, I >> recommend that we immediately move this patch to the 2017-07 CF. > > Seconded. And of course I meant Feb 28. -- -David

Re: [HACKERS] Statement-level rollback

On 2017-03-03 11:54:06 -0500, David Steele wrote: > Given that this landed on March 28 with no discussion beforehand, I > recommend that we immediately move this patch to the 2017-07 CF. Seconded. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] Statement-level rollback

On 3/3/17 2:43 AM, Tsunakawa, Takayuki wrote: > From: Tom Lane [mailto:t...@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

Re: [HACKERS] Statement-level rollback

From: Tom Lane [mailto:t...@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

Re: [HACKERS] Statement-level rollback

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Peter Eisentraut > On 2/28/17 02:39, Tsunakawa, Takayuki wrote: > > I'd like to propose statement-level rollback feature. To repeat myself, > this is requested for users to migrate from other DBMSs

Re: [HACKERS] Statement-level rollback

Peter Eisentraut writes: > On 2/28/17 08:17, Tom Lane wrote: >> I do not really see how this would ever get past the compatibility >> problems that forced us to give up on server-side autocommit years ago. > I think it's different because it's not a global

Re: [HACKERS] Statement-level rollback

On 2/28/17 02:39, Tsunakawa, Takayuki wrote: > I'd like to propose statement-level rollback feature. To repeat myself, this > is requested for users to migrate from other DBMSs to PostgreSQL. They > expect that a failure of one SQL statement should not abort the entire > transaction and their

Re: [HACKERS] Statement-level rollback

On 2/28/17 08:17, Tom Lane wrote: > I do not really see how this would ever get past the compatibility > problems that forced us to give up on server-side autocommit years ago. I think it's different because it's not a global setting, it's only a behavior you select explicitly when you start a

Re: [HACKERS] Statement-level rollback

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tom Lane > "Tsunakawa, Takayuki" writes: > > As I stated here and at the PGConf.ASIA developer meeting last year, > > I'd like to propose statement-level rollback

Re: [HACKERS] Statement-level rollback

"Tsunakawa, Takayuki" writes: > As I stated here and at the PGConf.ASIA developer meeting last year, I'd > like to propose statement-level rollback feature. I do not really see how this would ever get past the compatibility problems that forced us to give up on

[HACKERS] Statement-level rollback

Hello, As I stated here and at the PGConf.ASIA developer meeting last year, I'd like to propose statement-level rollback feature. To repeat myself, this is requested for users to migrate from other DBMSs to PostgreSQL. They expect that a failure of one SQL statement should not abort the