| From: | "Gokulakannan Somasundaram" <gokul007(at)gmail(dot)com> |
|---|---|
| To: | "Gregory Stark" <stark(at)enterprisedb(dot)com> |
| Cc: | "Neil Conway" <neilc(at)samurai(dot)com>, "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com>, "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>, "Roberts, Jon" <Jon(dot)Roberts(at)asurion(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: autonomous transactions |
| Date: | 2008-01-23 20:47:50 |
| Message-ID: | 9362e74e0801231247o16dca7e7xdf317c5b02876ed1@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>
>
>
> I think the hard part would be error handling. You have to be able to
> catch
> any errors and resume the outer transaction.
>
I think this is not right. Autonomous transactions are used as soon as you
catch a error in order to log them. It can be used even for auditing. But
resuming the outer transaction etc should not be on the plate of autonomous
transactions. I am making an example here ...
Suppose you want to write a code which captures the attempt to change the
sensitive information, and also fails the change made to sensitive
information. In order to fail the change, we might need to rollback the
transaction, which would prevent the attempt being logged. So if we have
autonomous audit transaction, it will commit irrespective of the rollback
which happened to the original transaction
The Audit transaction, which is a autonomous transaction need not catch any
error and resume the outer transaction.
Thanks,
Gokul.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2008-01-23 21:16:47 | Re: autonomous transactions |
| Previous Message | Gokulakannan Somasundaram | 2008-01-23 19:45:02 | Re: [HACKERS] Including Snapshot Info with Indexes |