Rollback on Error

[Michael Paesold]

I just read this in the MySQL manual:
(http://dev.mysql.com/doc/mysql/en/In..._handling.html)

"Error handling in InnoDB is not always the same as specified in the SQL
standard. According to the standard, any error during an SQL statement
should cause the rollback of that statement. InnoDB sometimes rolls back
only part of the statement, or the whole transaction. The following items
describe how InnoDB performs error handling:"

Ignore InnoDB, but read "According to the standard, any error during an SQL
statement should cause the rollback of that statement"...

I though the postgres behaviour of rolling back the whole transaction was
standard? If that is not the case, I don't understand why core seems to be
against a mode (GUC), where an implicit savepoint is generated before each
statement so that "rollback of the last statement" would be possible.

Is MySQL wrong on the standard, or has postgresql core attitude changed to
support the standard where possible - at least if the user wants?

Best Regards,
Michael Paesold

P.S: again thanks for PostgreSQL!


---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org

[Martijn van Oosterhout]

On Tue, Sep 14, 2004 at 11:39:32AM +0200, Michael Paesold wrote:

I though the postgres behaviour of rolling back the whole transaction was
standard? If that is not the case, I don't understand why core seems to be
against a mode (GUC), where an implicit savepoint is generated before each
statement so that "rollback of the last statement" would be possible.
Well. If such a mode ever becomes available I'll be looking into how to
make sure it never gets turned on. My mind is currently boggling at the
number of things it would break.

A transaction is either committed as a whole, without errors, or not at
all. If you want to do a savepoint after each statement, go right
ahead, nothing is stopping you. I just don't think making it any kind
of default is a very good idea...
--
Martijn van Oosterhout <kl*****@svana.org> http://svana.org/kleptog/ Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
tool for doing 5% of the work and then sitting around waiting for someone
else to do the other 95% so you can sue them.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQFBRr+MY5Twig3Ge+YRAoC3AJ9dcQ3buvSAZ/kVTgL9HQuHdkWCUACeIjXp
lqhKpNbi5kLWRJjaQ5dbVhc=
=wqxC
-----END PGP SIGNATURE-----

[Peter Eisentraut]

Michael Paesold wrote:

I though the postgres behaviour of rolling back the whole transaction
was standard?
No.
If that is not the case, I don't understand why core
seems to be against a mode (GUC), where an implicit savepoint is
generated before each statement so that "rollback of the last
statement" would be possible.

Because it's dangerous in noninteractive mode. When you send a
transaction to the server, you don't want some statements be left out.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

[Michael Paesold]

Peter Eisentraut wrote:

Michael Paesold wrote:

I though the postgres behaviour of rolling back the whole transaction
was standard?

No.

Thanks for putting that straigt.

If that is not the case, I don't understand why core
seems to be against a mode (GUC), where an implicit savepoint is
generated before each statement so that "rollback of the last
statement" would be possible.

Because it's dangerous in noninteractive mode. When you send a
transaction to the server, you don't want some statements be left out.

I understand it's dangerous, it would possibly introduce data-inconsistency
in all applications that don't check for errors after each statement...

Still it would be very useful in interactive psql...
of course, it's bad in scripted mode. Perhaps it could be implemented inside
psql? Would such a patch be accepted?

Regards,
Michael Paesold
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

[Csaba Nagy]

On Tue, 2004-09-14 at 11:56, Peter Eisentraut wrote:

Michael Paesold wrote:

I though the postgres behaviour of rolling back the whole transaction
was standard?

No.

If that is not the case, I don't understand why core
seems to be against a mode (GUC), where an implicit savepoint is
generated before each statement so that "rollback of the last
statement" would be possible.

Because it's dangerous in noninteractive mode. When you send a
transaction to the server, you don't want some statements be left out.

But it does not mean the server will commit the transaction for you...
it will throw an exception on the failed query, and it's up to you to
continue the transaction, commit it right away, or to roll it back. Old
code will probably just work fine if it will roll back on any received
error, which it had to do anyway even with the current behavior.
So it is just giving more choice to the developer instead of deciding
for him that the transaction is failed... and yes, there are valid
scenarios where it is quicker to execute a query and based on the fact
that it fails or not do different things, without the need of redoing
the whole transaction executed before.
It's another story that this feature should not be turned on by default
if it has some performance overhead (which I suppose it has, as setting
a savepoint is probably not free).

Just my 2c,
Csaba.

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org

[Paul Thomas]

On 14/09/2004 10:39 Michael Paesold wrote:

I just read this in the MySQL manual:
(http://dev.mysql.com/doc/mysql/en/In..._handling.html)

"Error handling in InnoDB is not always the same as specified in the SQL
standard. According to the standard, any error during an SQL statement
should cause the rollback of that statement. InnoDB sometimes rolls back
only part of the statement, or the whole transaction. The following items
describe how InnoDB performs error handling:"

Ignore InnoDB, but read "According to the standard, any error during an
SQL
statement should cause the rollback of that statement"...

I though the postgres behaviour of rolling back the whole transaction was
standard? If that is not the case, I don't understand why core seems to be
against a mode (GUC), where an implicit savepoint is generated before each
statement so that "rollback of the last statement" would be possible.

Is MySQL wrong on the standard, or has postgresql core attitude changed to
support the standard where possible - at least if the user wants?

Well, you could go off and read the standards of course but I'll save you
the time and tell you that PostrgreSQL does it correctly.

But seriously, are you so naive that you would believe _anything_ MySQL AB
say?
--
Paul Thomas
+------------------------------+-------------------------------------------+
| Thomas Micro Systems Limited | Software Solutions for Business |
| Computer Consultants | http://www.thomas-micro-systems-ltd.co.uk |
+------------------------------+-------------------------------------------+

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org

[Tom Lane]

"Michael Paesold" <mp******@gmx.at> writes:

I though the postgres behaviour of rolling back the whole transaction was
standard?
Not really.
If that is not the case, I don't understand why core seems to be
against a mode (GUC), where an implicit savepoint is generated before each
statement so that "rollback of the last statement" would be possible.

Because we learned our lesson with the ill-fated autocommit GUC
variable. You can't have fundamental transactional semantics depending
on the phase of the moon, but from the point of view of application
code, anything that can be flipped as easily as a GUC variable is an
unknown.

If you've been following recent -hackers discussions you will also
realize that a forced savepoint for every statement is untenable
from a performance perspective anyway.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

[Michael Paesold]

Tom Lane wrote:

"Michael Paesold" <mp******@gmx.at> writes:

....

If that is not the case, I don't understand why core seems to be
against a mode (GUC), where an implicit savepoint is generated before each statement so that "rollback of the last statement" would be possible.

Because we learned our lesson with the ill-fated autocommit GUC
variable. You can't have fundamental transactional semantics depending
on the phase of the moon, but from the point of view of application
code, anything that can be flipped as easily as a GUC variable is an
unknown.

If you've been following recent -hackers discussions you will also
realize that a forced savepoint for every statement is untenable
from a performance perspective anyway.

Well, I read the threads "Re: beta1 & beta2 & Windows & heavy load" and
"Cleaning up recovery from subtransaction start failure".

I see, that savepoint/subxacts are rather expensive, at least wrt
shared-memory (lock on xid).

On the other hand, the scenario of a psql option (read: I have given up the
idea of a backend implementation) to rollback only last statement on error
is quite different.

In the mentioned thread, several thousand rows where deleted, each firing a
trigger creating a subxact. But in usual interactive administrative
sessions, you would perhaps have 5 to 20 statements in a usual transaction.
At least according to my personal experience.

Am I right in asserting that psql could recognize if a session is
interactive or scripted (\i, psql < script.sql)? And it already has user
settable options, (\set, e.g. autocommit)...

So a proper patch implementing a corresponding mode in psql that wraps each
statement (of a multi statement transaction) in a subxact, if the user
enables it, would be accepted or even called welcome?

Just thinking about...

BEGIN;
SET TRANSACTION ISOLATION SERIALIZABLE;
SELECT * FROM a WHERE id = 5;
UPDATE a SET .... WHERE id = 5;

-- check everything is ok...
SELEC * FROM a WHERE id = 5;

--> ERROR: syntax error at or near "SELEC" at character 1

-- arghh... typo do it all over again...

Best Regards,
Michael Paesold
---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

[Tom Lane]

"Michael Paesold" <mp******@gmx.at> writes:

Tom Lane wrote:

"Michael Paesold" <mp******@gmx.at> writes:

If that is not the case, I don't understand why core seems to be
against a mode (GUC), where an implicit savepoint is generated before
each statement so that "rollback of the last statement" would be possible.
Because we learned our lesson with the ill-fated autocommit GUC
variable. You can't have fundamental transactional semantics depending
on the phase of the moon, but from the point of view of application
code, anything that can be flipped as easily as a GUC variable is an
unknown.

On the other hand, the scenario of a psql option (read: I have given up the
idea of a backend implementation) to rollback only last statement on error
is quite different.

Sure (and we already have one for autocommit). But I thought you were
asking about a backend implementation.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend