Обсуждение: transaction rollbacks on error

Hi all

I hope no one finds this the wrong Mailing List, but I would like to
request/propose a change in PostGres.  (I may even hack this one in
myself if no one objects.)

It seems that ANY error in postgres voids the entire transaction.  I.e.
if an error occurs, one must immediately commit decide to commit or
rollback the current transaction.  No further updates will be accepted
until this is done.  I am almost postive that most commercial databases
do not behave this way.  (I do not think that DB2 does, but I have had
very little to do with other databases since discovering Postgresql! ;-)
At the VERY least it would be nice to have a user option whereby errors
would not affect the current transaction state.



--
===
Peace,
Peter

We are Microsoft of Borg, you will be assimilated!!!
Resistance is fut...  ***BZZZRT***  THUD!!!
[General Protection Fault in MSBorg32.DLL]
Please contact the Vendor of this Borg for more Information

--

Peter Garner wrote:
> 
> Hi all
> 
> I hope no one finds this the wrong Mailing List, but I would like to
> request/propose a change in PostGres.  (I may even hack this one in
> myself if no one objects.)
> 
> It seems that ANY error in postgres voids the entire transaction.  I.e.
> if an error occurs, one must immediately commit decide to commit or
> rollback the current transaction.  No further updates will be accepted
> until this is done.  I am almost postive that most commercial databases
> do not behave this way.  (I do not think that DB2 does, but I have had
> very little to do with other databases since discovering Postgresql! ;-)
> At the VERY least it would be nice to have a user option whereby errors
> would not affect the current transaction state.

I'm going to implement savepoints (and _implicit_ savepoints)
in 6.6.

Vadim

>From man begin:
      This command begins a user transaction which Postgres will      guarantee is serializable with respect to all
concurrently     executing  transactions.   Postgres uses two-phase locking      to perform this task.  If the
transaction is  committed,      Postgres  will ensure that all updates are done or none of      them  are  done.
Transactions have  the  standard  ACID      (atomic, consistent, isolatable, and durable) property.
 


Peter Garner ha scritto:

> Hi all
>
> I hope no one finds this the wrong Mailing List, but I would like to
> request/propose a change in PostGres.  (I may even hack this one in
> myself if no one objects.)
>
> It seems that ANY error in postgres voids the entire transaction.  I.e.
> if an error occurs, one must immediately commit decide to commit or
> rollback the current transaction.  No further updates will be accepted
> until this is done.  I am almost postive that most commercial databases
> do not behave this way.  (I do not think that DB2 does, but I have had
> very little to do with other databases since discovering Postgresql! ;-)
> At the VERY least it would be nice to have a user option whereby errors
> would not affect the current transaction state.
>
> --
> ===
> Peace,
> Peter
>
> We are Microsoft of Borg, you will be assimilated!!!
> Resistance is fut...  ***BZZZRT***  THUD!!!
> [General Protection Fault in MSBorg32.DLL]
> Please contact the Vendor of this Borg for more Information
>
> --

--
______________________________________________________________
PostgreSQL 6.5.0 on i586-pc-linux-gnu, compiled by gcc 2.7.2.3
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Jose'

José Soares wrote:
> 
> >From man begin:
> 
>        This command begins a user transaction which Postgres will
>        guarantee is serializable with respect to all concurrently                     ^^^^^^^^^^^^
>        executing  transactions.   Postgres uses two-phase locking
^^^^^^^^^^^^^^^^^
>        to perform this task.  If the  transaction  is  committed,
>        Postgres  will ensure that all updates are done or none of
>        them  are  done.   Transactions  have  the  standard  ACID
>        (atomic, consistent, isolatable, and durable) property.

Ops. This man page must be changed too. I'll do it tomorrow.

Seems that it's too late to update begin.sgml as well?
Thomas?

Vadim

> Seems that it's too late to update begin.sgml as well?
> Thomas?

It is ok to update since it is in docs not yet formatted. I'll start
the User's Guide tomorrow, or perhaps tonight if I see your changes.
                   - Thomas

-- 
Thomas Lockhart                lockhart@alumni.caltech.edu
South Pasadena, California

Thomas Lockhart wrote:
> 
> > Seems that it's too late to update begin.sgml as well?
> > Thomas?
> 
> It is ok to update since it is in docs not yet formatted. I'll start
> the User's Guide tomorrow, or perhaps tonight if I see your changes.

Please do it tomorrow - I'm going home soon...

Vadim