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:she...@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 : http://archives.postgresql.org/pgsql-hackers/2008-01/msg00893.php https://labs.omniti.com/trac/pgtreats/browser/trunk/autonomous_logging_tool ... 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
