Re: transaction processing after error in statement - Mailing list pgsql-sql

From Rajesh Kumar Mallah
Subject Re: transaction processing after error in statement
Date
Msg-id 3FB1366E.9030805@trade-india.com
Whole thread Raw
In response to Re: transaction processing after error in statement  (Rod Taylor <pg@rbt.ca>)
Responses Re: transaction processing after error in statement
List pgsql-sql
Rod Taylor wrote:<br /><blockquote cite="mid1068490585.25089.7.camel@jester" type="cite"><blockquote type="cite"><pre
wrap="">berecovered either. When committing a transaction the effects of all
 
operations that did not fail will be made permanent. This is how
transaction processing is described in the literature.   </pre></blockquote><pre wrap="">
I would be interested in reading that (URLs please) as I didn't see
anything in the spec that was interesting on this topic.

4.8.5 from Framework (part 01)       An SQL-transaction (transaction) is a sequence of executions of
SQL-statementsthat is atomic with respect to recovery. That is       to say: either the execution result is completely
successful,or       it has no effect on any SQL-schemas or SQL-data.</pre></blockquote> Although i am not aware of the
rootsof this discussion but would like to<br /> comment at this point .<br /><br /> When we work with sequences an
abortedtransaction does have<br /> a permanent effect on the last value  of sequence. Is this behaviour <br /> not a
violationof above defination of transaction ?<br /><br /><br /> Regds<br /> Mallah.<br /><br /><blockquote
cite="mid1068490585.25089.7.camel@jester"type="cite"><pre wrap="">
 

The "execution result is completely successful" could certainly be used
to back up PostgreSQLs choice to force a rollback. However, it doesn't
differentiate between execution of what the user requested, and
execution of recovery procedures on the successful user elements.

Irregardless, I wish a commit on a failed transaction would throw an
error -- END is good enough for Rollback or Commit.

For PostgreSQL to implement this we need Savepoints or nested
transactions internally since in many cases data is physically written
in order to perform things like Foreign Key constraint checks.


---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
              <a class="moz-txt-link-freetext"
href="http://www.postgresql.org/docs/faqs/FAQ.html">http://www.postgresql.org/docs/faqs/FAQ.html</a>
</pre></blockquote><br/> 

pgsql-sql by date:

Previous
From: Gaetano Mendola
Date:
Subject: Re: Dynamic Query for System functions - now()
Next
From: Rod Taylor
Date:
Subject: Re: transaction processing after error in statement