Hello,
I have a much clearer picture of the issue. So, does this mean that
with nested transactions, all statements will execute within a
mini-transaction, which may be executed within a branch of user
defined sub-transactions. Such that:
begin
...
...
begin
...
...
Bruce Momjian [EMAIL PROTECTED] writes:
Imagine this:
BEGIN WORK;
LOCK oldtab;
CREATE_X TABLE newtab AS SELECT * FROM oldtab;
DELETE oldtab;
COMMIT
In this case, you would want the database to abort on a syntax error, right?
Certainly not if I was typing
Rod Taylor wrote:
BEGIN WORK;
LOCK oldtab;
CREATE_X TABLE newtab AS SELECT * FROM oldtab;
DELETE oldtab;
COMMIT
In this case, you would want the database to abort on a syntax error, right?
Certainly not if I was typing
Bruce Momjian [EMAIL PROTECTED] writes:
Josh Berkus wrote:
Hmmm I'm not sure how you arrived at this wording for the TODO. How are
we defining a syntax error?
Parser error, I would say. Misspelling a table name, perhaps.
FWIW, a misspelled table name is plainly a semantic error, not
Oh, yea, that would be bad. So you want to invalidate the entire
session on any error? That could be done.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
Well, that's exactly the current behaviour, which creates
Can we clarify what is meant by the client? It is my
expectation/desire that the client library would handle this as a
setting similar to AutoCommit, which would implicitly protect each
statement within a nested block (savepoint), causing only itself to
abort. Such as, OnError=[abort|continue],
In both cases, the transaction either commits or rollback occurs. No
other option is possible at the end of the transaction, but in the first
style of transaction semantics you get a mid-way decision point. This
only refers to retryable errors, since errors like access rights
violations and
Zeugswetter Andreas SB SD [EMAIL PROTECTED] writes:
It seems to me, that leaving all this to the client (which implicitly
inserts savepoints) can never be as efficient as a serverside feature.
I think this is an overly narrow view of efficiency. With client
control, the client can insert
It seems to me, that leaving all this to the client (which implicitly
inserts savepoints) can never be as efficient as a serverside feature.
I think this is an overly narrow view of efficiency. With client
control, the client can insert savepoints whereever it needs them,
Yes, but not
Bruce,
So, whatever error handling mode conveniences we wish to put in should
be put in on the client side.
Added to TODO:
* Use nested transactions to prevent syntax errors from aborting
a transaction
Hmmm I'm not sure how you arrived at this wording for the
Zeugswetter Andreas SB SD [EMAIL PROTECTED] writes:
which might not be for every statement. Savepoints that you don't
actually need are going to be a fairly expensive overhead, AFAICS.
Well with other db's per statement rollback is a no overhead feature,
so this is pg specific.
I very much
Josh Berkus wrote:
Bruce,
So, whatever error handling mode conveniences we wish to put in should
be put in on the client side.
Added to TODO:
* Use nested transactions to prevent syntax errors from aborting
?a transaction
Hmmm I'm not sure how you
Improving on not ideal would be good, and would get even closer to
full Oracle/SQLServer migration/compatibility. However, since I've never
looked at that section of code, I couldn't comment on any particular
approach nor implement such a change, so I'll shut up and be patient.
Imagine
On Thu, Feb 12, 2004 at 09:55:36AM +0100, Zeugswetter Andreas SB SD wrote:
Yeah, but in other db's this is solved by the frontend. e.g. in Informix
dbaccess has a mode that simply stops execution upon first error. So I don't
think this is a nogo argument, if we added such a feature to psql.
Zeugswetter Andreas SB SD wrote:
Improving on not ideal would be good, and would get even closer to
full Oracle/SQLServer migration/compatibility. However, since I've never
looked at that section of code, I couldn't comment on any particular
approach nor implement such a change, so I'll
Jeroen T. Vermeulen [EMAIL PROTECTED] writes:
It does require that the application be meticulous in its checking though.
Existing client programs, for instance, may ignore any errors coming back
from PQexec() during the transaction and just see if the COMMIT succeeds.
Such could would break in
Greg Stark wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Imagine this:
BEGIN WORK;
LOCK oldtab;
CREATE_X TABLE newtab AS SELECT * FROM oldtab;
DELETE oldtab;
COMMIT
In this case, you would want the database to abort on a syntax error, right?
BEGIN WORK;
LOCK oldtab;
CREATE_X TABLE newtab AS SELECT * FROM oldtab;
DELETE oldtab;
COMMIT
In this case, you would want the database to abort on a syntax error, right?
Certainly not if I was typing this from the command line. Imagine the
frustration if the
In this case, you would want the database to abort on a syntax error, right?
Am I completely off thread to ask why HOW we allow an abort on syntax
errors? (at least in regard to stored functions)
Shouldn't PostgreSQL do somethng intellignet like *notice* the syntax
error in the stored function
Bruce Momjian
Simon Riggs wrote:
Tom Lane
Simon Riggs [EMAIL PROTECTED] writes:
Most importantly, other references I have state that: the ANSI
SQL-99
specification does require that if a statement errors then only
that
statement's changes are rolled back.
...if anybody
Bruce Momjian [EMAIL PROTECTED] writes:
Rod Taylor wrote:
Can this be done entirely on the client side?
Have psql silently wrap every statement going out with a BEGIN and a
COMMIT or ROLLBACK depending on whether there was an error or not?
Yep, we could do it in the client like we do for
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Rod Taylor wrote:
Can this be done entirely on the client side?
Have psql silently wrap every statement going out with a BEGIN and a
COMMIT or ROLLBACK depending on whether there was an error or not?
Yep, we could do it in the
Simon Riggs wrote:
Tom Lane
Simon Riggs [EMAIL PROTECTED] writes:
Most importantly, other references I have state that: the ANSI
SQL-99
specification does require that if a statement errors then only that
statement's changes are rolled back.
...if anybody has a copy of the actual
Simon Riggs wrote:
I've have tried to work out which section of the manual to document this
in. The most likely section would seem to be: doc/src/sgml/mvcc.sgml,
which is the Concurrency Control chapter of the User's Guide (on PDF).
I'd suggest including an extra sect1 section like
Andrej Czapszys
This is a major bug which greatly diminishes the confidence of my
co-workers in postgresql.
This is NOT a bug. Transactional robustness is important and PostgreSQL
has a very strict implementation in this area.
Greg Stark
Bruce Momjian [EMAIL PROTECTED] writes:
Edwin S.
Simon Riggs [EMAIL PROTECTED] writes:
Most importantly, other references I have state that: the ANSI SQL-99
specification does require that if a statement errors then only that
statement's changes are rolled back.
No. The spec says
The execution of a rollback statement may be
Tom Lane [EMAIL PROTECTED] writes:
What it comes down to is that a lot of code in the backend assumes that
transaction abort can be relied on to do any post-elog cleanup needed,
such as releasing locks or reclaiming leaked memory. I don't think we
can afford to give up that assumption; the
Greg Stark [EMAIL PROTECTED] writes:
So you picture the backend automatically introducing a mini-nested-transaction
for every request and automatically rolling that back on any error. So the
application or user wouldn't have to do anything to continue processing
ignoring the error?
You're
Gavin Sherry wrote:
Its not that there's a rationale behind it. Rather, the existing error
handling code *has* to abort the current transaction because an error has
taken place. In a multi statement transaction block (ie, BEGIN; ...; ...;
... COMMIT;) each statement piggy backs on onto the whole
Bruce Momjian [EMAIL PROTECTED] writes:
Edwin S. Ramirez wrote:
Hello,
Is is possible to change the transaction behaviour not to abort when a
syntax error occurs.
I've done some searches on the list, and have not found anything.
No, we need nested transactions for that. We are
On Mon, 8 Feb 2004, Greg Stark wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Edwin S. Ramirez wrote:
Hello,
Is is possible to change the transaction behaviour not to abort when a
syntax error occurs.
I've done some searches on the list, and have not found anything.
No,
Greg Stark [EMAIL PROTECTED] writes:
But why does the database enforce that every syntax error *requires* a
transaction roll back?
PG enforces that every error requires a transaction abort. Period, full
stop. Picking and choosing which errors might not really require a
rollback involves a
Hello,
Is is possible to change the transaction behaviour not to abort when a
syntax error occurs.
I've done some searches on the list, and have not found anything.
-ESR-
---(end of broadcast)---
TIP 6: Have you searched our list archives?
On Fri, Jan 30, 2004 at 07:43:06AM -0800, Edwin S. Ramirez wrote:
Is is possible to change the transaction behaviour not to abort when a
syntax error occurs.
Not currently.
--
Alvaro Herrera (alvherre[a]dcc.uchile.cl)
And as an added bonus, now my computer goes to the toilet for me, leaving
Edwin S. Ramirez wrote:
Hello,
Is is possible to change the transaction behaviour not to abort when a
syntax error occurs.
I've done some searches on the list, and have not found anything.
No, we need nested transactions for that. We are working on it or at
least have a plan.
--
35 matches
Mail list logo
