Autonomous transaction
in [PgSql]
|
Prev: [HACKERS] Autonomous transaction
Next: pgsql: Check compulsory parametersin recovery.conf in standby_mode, per
From: Robert Haas on 5 Apr 2010 11:43 On Sun, Apr 4, 2010 at 10:26 AM, Loïc Vaumerel <shefla(a)gmail.com> wrote: > Is there a way to use real and clean autonomous transactions in PostgreSQL > yet ? No. > If no, is it planned to do so ? When ? To my knowledge, no one is working on this. ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Jaime Casanova on 5 Apr 2010 12:11 On Sun, Apr 4, 2010 at 10:26 AM, Loïc Vaumerel <shefla(a)gmail.com> wrote: [...] > 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. > the only side effect i can think of is that you will use another connection slot (that's because dblink will stablish a new connection) -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL AsesorÃa y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Dimitri Fontaine on 6 Apr 2010 07:35 Loïc Vaumerel <shefla(a)gmail.com> writes: > 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. See plproxy which is designed for this kind of work. Or about⦠> Is there a way to use real and clean autonomous transactions in > PostgreSQL yet ? None that I know of. > If no, is it planned to do so ? When ? We get demands quite often, it seems it's one of the "big tickets" we're still missing. I don't remember any development effort proposal, though. Regards, -- dim -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: pg on 6 Apr 2010 07:56 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(a)gmail.com] Sent: Sunday, April 4, 2010 10:26 AM To: pgsql-hackers(a)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
From: Bruce Momjian on 13 Apr 2010 20:01 pg(a)thetdh.com wrote: > 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. Yea, having some things in our system be non-transactional is odd and hard to understand. Just thinking about it, it seems it would introduce all sorts of odd behaviors. -- Bruce Momjian <bruce(a)momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
|
Next
|
Last
Pages: 1 2 Prev: [HACKERS] Autonomous transaction Next: pgsql: Check compulsory parametersin recovery.conf in standby_mode, per |