Re: transaction processing after error in statement
От | Rajesh Kumar Mallah |
---|---|
Тема | Re: transaction processing after error in statement |
Дата | |
Msg-id | 3FB1366E.9030805@trade-india.com обсуждение исходный текст |
Ответ на | Re: transaction processing after error in statement (Rod Taylor <pg@rbt.ca>) |
Ответы |
Re: transaction processing after error in statement
|
Список | 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 по дате отправления: