It would be useful to have a relation such that all dirtied buffers got written out even for failed transactions (barring a crash) and such that read-any-undeleted were easy to do, despite the non-ACIDity. The overhead of a side transaction seems overkill for such things as logs or advisory relations, and non-DB files would be harder to tie in efficiently to DB activity. A side transaction would still have to be committed in order to be useful; either you're committing frequently (ouch!), or you risk failing to commit just as you would the main transaction.
David Hudson
-----Original Message-----
From: Loïc Vaumerel [mailto:shefla@gmail.com]
Sent: Sunday, April 4, 2010 10:26 AM
To: pgsql-hackers@postgresql.org
Subject: [HACKERS] Autonomous transaction
Hi,
I have an application project based on a database.
I am really interested in using PostgreSQL.
I have only one issue, I want to use autonomous transactions to put in place a debug / logging functionality.
To do so, I insert messages in a "debug" table.
The problem is, if the main transaction / process rollback, my debug message insert will be rolled back too.
This is not the behavior I wish.
I need a functionality with the same behavior than the Oracle "PRAGMA AUTONOMOUS_TRANSACTION" one.
I have searched for it in the documentation and on the net, unfortunately nothing. (maybe I missed something)
I just found some posts regarding this :
... and some others ...
All solutions I found are working the same way : they use dblink.
I consider these solution more as handiwork than a clean solution.
I am a little bit concerned about side effects as dblink were not intially designed for this.
So my questions :
Is there a way to use real and clean autonomous transactions in PostgreSQL yet ?
If no, is it planned to do so ? When ?
Thanks in advance
Best regards
Shefla
