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
> feedback for the specification and design based on th
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
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
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 inside
> explicit transaction blocks.
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.
T
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,
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 close to negligible.
Yep. Not
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 netwo
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
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.
> It
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 AS SELECT * FROM t1;
DROP TABLE t1
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
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 add this patch to CommitFest 2017-3
> 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:
The code for stored functions is not written yet, but I'd like your
fe
> 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 for the specification and design based on the current pat
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
>> patch to CommitFest 2017-3.
>
> Thi
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.
--
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 years ago.
>
>> I think it's different because it's not
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 breakage.
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 legrand
Objet : Re: Statement-level rollback
Ple
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
ср, 8
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
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 conte
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 still receiving the famous
>
>
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
>
> JDBC has it since 9.4.1210
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:
https://github.com/
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 (a
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"
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 statement-level rollback feature. To repeat m
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 discussio
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 Geoghegan
--
Sent via
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
da...@pgm
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 subs
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 DBMSes
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 pressur
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
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 setting, it's only a
> behavior you sele
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
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 tra
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 feature.
>
> I do not really see h
"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 server-side autocommit years ago.
41 matches
Mail list logo
