From: | Kasia Tuszynska <ktuszynska(at)esri(dot)com> |
---|---|
To: | "pgsql-admin(at)postgresql(dot)org" <pgsql-admin(at)postgresql(dot)org> |
Subject: | transaction error handling |
Date: | 2011-11-29 17:57:24 |
Message-ID: | 232B5217AD58584C87019E8933556D11036BDE58EB@redmx2.esri.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin pgsql-bugs |
Hi Everybody,
This is an architectural question.
I am testing on Postgres 9.0.2 on windows and linux(suse, rhel, ubuntu)
I want to make sure that I have the correct understanding of the Postgres architecture and would like to enquire if there are any plans to change it.
Comparing Oracle and Postgres from the perspective of error handling on the transaction level I observed the following:
Oracle:
Begin transaction
Insert - no error
Implicit savepoint
Insert - error raised
Implicit rollback to the savepoint, no transaction loss, error raised on the insert statement that errored out.
End transaction, implicit commit, with the single error free insert.
Postgres:
Begin transaction
Insert - no error
Insert - error raised
Transaction loss = no implicit rollback to the single error free insert.
Is this a correct interpretation of the Postgres transaction error handling?
If so, are there any changes being considered, or perhaps already implemented?
Sincerely,
Kasia
From | Date | Subject | |
---|---|---|---|
Next Message | Craig James | 2011-11-29 18:15:32 | Deadlock on "select ... for update"? |
Previous Message | David Schnur | 2011-11-29 15:28:33 | Re: Repeatable crash in pg_dump (with -d2 info) |
From | Date | Subject | |
---|---|---|---|
Next Message | Rob Richardson | 2011-11-29 18:34:49 | Re: transaction error handling |
Previous Message | Balser, Robert W | 2011-11-29 16:20:00 | Re: BUG #6304: initdb fails with loale ko_KR.eucKR |