On 12/2/2004 3:18 AM, Thomas Hallgren wrote:
Jan,
... plus that the catch-nesting automatically represents the
subtransaction nesting. I can't really see any reason why those two
should not be bound together. Does anybody?
That depends on what you mean. As a stop-gap solution, cerntanly. But in
Jan Wieck wrote:
There is no try in Tcl.
The syntax is
catch { block-of-commands } [variable-name]
Catch returns a numeric result, which is 0 if there was no exception
thrown inside of the block-of-commands. The interpreter result, which
would be the exceptions error message in cleartext, is
On 12/3/2004 12:23 PM, Thomas Hallgren wrote:
Jan Wieck wrote:
There is no try in Tcl.
The syntax is
catch { block-of-commands } [variable-name]
Catch returns a numeric result, which is 0 if there was no exception
thrown inside of the block-of-commands. The interpreter result, which
would be the
Jan Wieck [EMAIL PROTECTED] writes:
Your suggestion to expose a plain savepoint interface to the programmer
leads directly to the possiblity to commit a savepoint made by a
sub-function in the caller and vice versa - which if I understood Tom
correctly is what we need to avoid.
If we
On Dec 3, 2004, at 2:04 PM, Jan Wieck wrote:
[snip]
The point we where coming from was Tom's proposal to wrap each and
every single SPI call into its own subtransaction for semantic
reasons. My proposal was an improvement to that with respect to
performance and IMHO also better matching the
James Robinson [EMAIL PROTECTED] writes:
The JDBC interface exposes the savepoint interface, via setSavepoint(),
releaseSavepoint(), and rollback(Savepoint sp) methods on the
Connection, and Thomas's design of PL/Java offers the SPI via mapping
it onto JDBC. Would client-side JDBC also
Jan Wieck wrote:
as you now suggest? I don't remember suggesting that. I concluded
from your statements that _you_ are against changing Tcl's catch but
instead want the savepoint functionality exposed to plain Tcl. So
_you_ are against _my_ suggestion because these two are mutually
exclusive.
Jan,
... plus that the catch-nesting automatically represents the
subtransaction nesting. I can't really see any reason why those two
should not be bound together. Does anybody?
That depends on what you mean. As a stop-gap solution, cerntanly. But in
the long run, I still think that savepoints
Tom Lane wrote:
Wrapping each individual SPI command in a subtransaction IN NO WAY
prevents us from adding programmer-controllable savepoint features
to the PL languages later.
Ah good - I was coming to the conclusion savepoints/exception handling
were both separately necessary.
It simply
Richard Huxton wrote:
Can I make some counter-proposals?
1. Wrap each function body/call (same thing here afaict) in a
sub-transaction. An exception can be caught within that function, and
all the spi in that function is then rolled back. This is rubbish, but
at least it's predictable and
Thomas Hallgren wrote:
Richard Huxton wrote:
Can I make some counter-proposals?
1. Wrap each function body/call (same thing here afaict) in a
sub-transaction. An exception can be caught within that function, and
all the spi in that function is then rolled back. This is rubbish, but
at least
Richard Huxton wrote:
But is the problem not that forgetting to use SAVEPOINT can get us in
trouble with clearing up after an exception?
I fail to see how that's different from forgetting to use pgtry instead
of try.
Regards,
Thomas Hallgren
---(end of
Thomas Hallgren wrote:
Richard Huxton wrote:
But is the problem not that forgetting to use SAVEPOINT can get us in
trouble with clearing up after an exception?
I fail to see how that's different from forgetting to use pgtry instead
of try.
It feels more distinct to me. I'll grant you I'm only a
On Wed, 01 Dec 2004 10:29:17 +0100, Thomas Hallgren
[EMAIL PROTECTED] wrote:
Richard Huxton wrote:
But is the problem not that forgetting to use SAVEPOINT can get us in
trouble with clearing up after an exception?
I fail to see how that's different from forgetting to use pgtry instead
On 12/1/2004 4:27 AM, Richard Huxton wrote:
Thomas Hallgren wrote:
Richard Huxton wrote:
Can I make some counter-proposals?
1. Wrap each function body/call (same thing here afaict) in a
sub-transaction. An exception can be caught within that function, and
all the spi in that function is then
Jan Wieck wrote:
This all would mean that however deeply nested a function call tree,
it would unwind and rollback everything up to the outermost catch. If
there is no catch used, no subtransactions are created and the
unwinding goes all the way up to the statement. If catch is used but
no spi
On 12/1/2004 9:23 AM, Jan Wieck wrote:
On 12/1/2004 4:27 AM, Richard Huxton wrote:
Thomas Hallgren wrote:
Richard Huxton wrote:
Can I make some counter-proposals?
1. Wrap each function body/call (same thing here afaict) in a
sub-transaction. An exception can be caught within that function, and
On Wednesday 01 December 2004 04:12, Thomas Hallgren wrote:
Richard Huxton wrote:
Can I make some counter-proposals?
1. Wrap each function body/call (same thing here afaict) in a
sub-transaction. An exception can be caught within that function, and
all the spi in that function is then
--- Jan Wieck [EMAIL PROTECTED] wrote:
On 12/1/2004 9:23 AM, Jan Wieck wrote:
On 12/1/2004 4:27 AM, Richard Huxton wrote:
Thomas Hallgren wrote:
Richard Huxton wrote:
Can I make some counter-proposals?
1. Wrap each function body/call (same thing
here afaict) in a
Richard Huxton,
It feels more distinct to me. I'll grant you I'm only a sample size of
1 though.
Perhaps more distinct, but:
- Using savepoints together with try/catch is not exactly an unknown
concept. Try Google and you'll see a fair amount of examples advocating
the approach that I suggest.
On 12/1/2004 1:35 PM, Brett Schwarz wrote:
--- Jan Wieck [EMAIL PROTECTED] wrote:
On 12/1/2004 9:23 AM, Jan Wieck wrote:
On 12/1/2004 4:27 AM, Richard Huxton wrote:
Thomas Hallgren wrote:
Richard Huxton wrote:
Can I make some counter-proposals?
1. Wrap each function body/call (same thing
Tom Lane wrote:
The real point here is that omitting the per-command subtransaction
ought to be a hidden optimization, not something that intrudes to the
point of having unclean semantics when we can't do it.
Sorry to be stupid here, but I didn't understand this when it was
disussed originally
Richard Huxton wrote:
Tom Lane wrote:
The real point here is that omitting the per-command subtransaction
ought to be a hidden optimization, not something that intrudes to the
point of having unclean semantics when we can't do it.
Sorry to be stupid here, but I didn't understand this when it was
Richard Huxton [EMAIL PROTECTED] writes:
Tom Lane wrote:
The real point here is that omitting the per-command subtransaction
ought to be a hidden optimization, not something that intrudes to the
point of having unclean semantics when we can't do it.
Sorry to be stupid here, but I didn't
Thomas Hallgren [EMAIL PROTECTED] writes:
I don't understand this either. Why a subtransaction at all?
Don't get me wrong. I fully understand that a subtransaction would make
error recovery possible. What I try to say is that the kind of error
recovery that needs a subtransaction is fairly,
Tom Lane wrote:
In the case of Perl I suspect it is reasonably possible to determine
whether there is an eval surrounding the call or not, although we
might have to get more friendly with Perl's internal data structures
than a purist would like.
Not really very hard. (caller(0))[3] should
Tom Lane wrote:
On what evidence do you base that claim? It's true there are no
existing Tcl or Perl functions that do error recovery from SPI
operations, because it doesn't work in existing releases. That does
not mean the demand is not there. We certainly got beat up on often
enough about the
Thomas Hallgren [EMAIL PROTECTED] writes:
From your statement it sounds like you want to use the subtransactions
solely in a hidden mechanism and completely remove the ability to use
them from the function developer. Is that a correct interpretation?
No; I would like to develop the ability
While your message was directed at Thomas, I think I share Thomas'
position; well, for the most part.
On Tue, 2004-11-30 at 11:21 -0500, Tom Lane wrote:
But I think it's a bogus design, because (a) it puts extra burden on the
function author who's already got enough things to worry about, and
James William Pye wrote:
I think I may hold a more of a hold nose stance here than Thomas. I am
not sure if I want to implement savepoint/rollback restrictions as I
can't help but feel this is something Postgres should handle; not me or
any other PL or C Function author.
I agree with this but
James William Pye [EMAIL PROTECTED] writes:
plpy being an untrusted language, I *ultimately* do not have control
over this. I can only specify things within my code. I *cannot* stop a
user from making an extension module that draws interfaces to those
routines that may rollback to a savepoint
Tom Lane wrote:
The fundamental point you are missing, IMHO, is that a savepoint is a
mechanism for rolling back *already executed* SPI commands when the
function author wishes that to happen.
Of course. That's why it's imperative that it is the developer that
defines the boundaries. I forsee
On 11/19/2004 7:54 PM, Tom Lane wrote:
Thomas Hallgren [EMAIL PROTECTED] writes:
My approach with PL/Java is a bit different. While each SPI call is
using a try/catch they are not using a subtransaction. The catch will
however set a flag that will ensure two things:
1. No more calls can be made
Jan Wieck [EMAIL PROTECTED] writes:
I don't agree that the right cure is to execute each and every statement
itself as a subtransaction. What we ought to do is to define a wrapper
for the catch Tcl command, that creates a subtransaction and executes
the code within during that.
What I
On 11/29/2004 10:43 PM, Tom Lane wrote:
Jan Wieck [EMAIL PROTECTED] writes:
I don't agree that the right cure is to execute each and every statement
itself as a subtransaction. What we ought to do is to define a wrapper
for the catch Tcl command, that creates a subtransaction and executes
the
On Sat, 2004-11-20 at 16:39 -0500, Tom Lane wrote:
You're right. You can *not* expose those as user-callable operations in
a PL language. Consider for example what will happen if the user tries
to roll back to a savepoint that was established outside your function
call, or tries to exit the
Tom Lane wrote:
There's an ancient saying I can make this code arbitrarily fast ...
if it doesn't have to give the right answer. I think that applies
here. Fast and unsafe is not how the Postgres project customarily
designs things.
I'm missing something, that's clear. Because I can't see why the
Tom Lane wrote:
James William Pye [EMAIL PROTECTED] writes:
I have been playing with RollbackToSavepoint and ReleaseSavepoint, but
per Neil's comments on IRC and the fact that I have to annoyingly
construct a List containing the savepoint name. I get the feeling that I
am not meant to use them.
Thomas Hallgren wrote
I'm planning to add subtransactions too, but my approach will be to
use the savepoint functionality already present in the
java.sql.Connection interface. Perhaps the plpy implementation could
do something similar. This is what I'm planning to implement:
In Java, safepoints
Tom Lane wrote:
Thomas Hallgren [EMAIL PROTECTED] writes:
My approach with PL/Java is a bit different. While each SPI call is
using a try/catch they are not using a subtransaction. The catch will
however set a flag that will ensure two things:
1. No more calls can be made from PL/Java
Thomas Hallgren [EMAIL PROTECTED] writes:
Tom Lane wrote:
That's what pltcl has always done, and IMHO it pretty well sucks :-(
it's neither intuitive nor useful.
Given that most SPI actions that you do doesn't elog (most of them are
typically read-only), it's far more useful than imposing
Tom Lane [EMAIL PROTECTED] writes:
(I'm sure we can do more to speed up subtransaction entry/exit than we have
so far.)
Is there anything that can be done to short circuit the _first_ layer of
subtransaction? I'm thinking there will be many cases like this where there's
one implicit
I wrote:
I get about 6900 vs 12800 msec, so for a simple pre-planned query
it's not quite a 50% overhead.
However, that was yesterday ;-). I did some profiling and found some
easy-to-knock-off hotspots. Today I'm measuring about 25% overhead
for a simple SELECT, which I think is entirely
On Fri, 2004-11-19 at 16:58 -0500, Tom Lane wrote:
What I think we ought to do is change both PL languages so that every
SPI call is executed as a subtransaction. If the call elogs, we can
clean up by aborting the subtransaction, and then we can report the
error message as a Perl or Tcl error
James William Pye [EMAIL PROTECTED] writes:
I have been playing with RollbackToSavepoint and ReleaseSavepoint, but
per Neil's comments on IRC and the fact that I have to annoyingly
construct a List containing the savepoint name. I get the feeling that I
am not meant to use them.
You're right.
Tom Lane wrote:
What I think we ought to do is change both PL languages so that every
SPI call is executed as a subtransaction. If the call elogs, we can
clean up by aborting the subtransaction, and then we can report the
error message as a Perl or Tcl error condition, which the function
author
Tom Lane wrote:
plperl's error handling is not completely broken, but it's close :-(
Consider for example the following sequence on a machine with a
relatively old Perl installation:
You just picked an easy way to trigger this. As you rightly observe,
there are others.
We can deal with this
Thomas Hallgren [EMAIL PROTECTED] writes:
My approach with PL/Java is a bit different. While each SPI call is
using a try/catch they are not using a subtransaction. The catch will
however set a flag that will ensure two things:
1. No more calls can be made from PL/Java to the postgres
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
This will slow down the PL SPI call operations in both languages, but
AFAICS it's the only way to provide error handling semantics that aren't
too broken for words.
Can you estimate the extent of the slowdown?
Without actually doing
49 matches
Mail list logo
