Re: [HACKERS] autonomous transactions

On Sat, Jan 7, 2017 at 5:30 PM, Andrey Borodin wrote: > The new status of this patch is: Ready for Committer I don't think that this thread has reached a conclusion yet. From what I can see the last patch does not apply, so I have moved the patch to next CF with "waiting on

Re: [HACKERS] autonomous transactions

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: tested, passed Documentation:tested, passed Here’s review of Background Sessions v2 patch. ===Purpose===

Re: [HACKERS] autonomous transactions

On 11/10/16 21:54, Merlin Moncure wrote: > On Tue, Oct 11, 2016 at 10:06 AM, Petr Jelinek wrote: >> On 10/10/16 16:44, Merlin Moncure wrote: >>> On Thu, Oct 6, 2016 at 3:53 PM, Simon Riggs wrote: On 6 October 2016 at 21:27, Robert Haas

Re: [HACKERS] autonomous transactions

2016-10-11 21:54 GMT+02:00 Merlin Moncure : > On Tue, Oct 11, 2016 at 10:06 AM, Petr Jelinek > wrote: > > On 10/10/16 16:44, Merlin Moncure wrote: > >> On Thu, Oct 6, 2016 at 3:53 PM, Simon Riggs > wrote: > >>> On 6 October 2016

Re: [HACKERS] autonomous transactions

On Tue, Oct 11, 2016 at 10:06 AM, Petr Jelinek wrote: > On 10/10/16 16:44, Merlin Moncure wrote: >> On Thu, Oct 6, 2016 at 3:53 PM, Simon Riggs wrote: >>> On 6 October 2016 at 21:27, Robert Haas wrote: I think we should

Re: [HACKERS] autonomous transactions

2016-10-11 17:06 GMT+02:00 Petr Jelinek : > On 10/10/16 16:44, Merlin Moncure wrote: > > On Thu, Oct 6, 2016 at 3:53 PM, Simon Riggs > wrote: > >> On 6 October 2016 at 21:27, Robert Haas wrote: > >>> I think we should implement

Re: [HACKERS] autonomous transactions

On 10/10/16 16:44, Merlin Moncure wrote: > On Thu, Oct 6, 2016 at 3:53 PM, Simon Riggs wrote: >> On 6 October 2016 at 21:27, Robert Haas wrote: >>> I think we should implement background transactions and call them >>> background transactions. That

Re: [HACKERS] autonomous transactions

On Thu, Oct 6, 2016 at 3:53 PM, Simon Riggs wrote: > On 6 October 2016 at 21:27, Robert Haas wrote: >> I think we should implement background transactions and call them >> background transactions. That allows us to expose additional >> functionality

Re: [HACKERS] autonomous transactions

On 2016-10-06 10:56:34 +0100, Simon Riggs wrote: > On 7 September 2016 at 20:46, Robert Haas wrote: > > On Sat, Sep 3, 2016 at 7:09 AM, Simon Riggs wrote: > > True. I believe this issue has been discussed before, and I think > > it's a solvable

Re: [HACKERS] autonomous transactions

On Thu, Oct 6, 2016 at 4:53 PM, Simon Riggs wrote: > For myself, I don't care what you call it. > > I just want to be able to invoke it by saying PRAGMA AUTONOMOUS_TRANSACTION; > and I know many others do also. To me, those statements are rather contradictory, and I don't

Re: [HACKERS] autonomous transactions

On 6 October 2016 at 21:27, Robert Haas wrote: >> * The labelling "Autonomous Transaction" is a simple coat of paint, >> which can easily be transferred to a better implementation if one >> comes. If one doesn't then its better to have something than nothing. >> So I

Re: [HACKERS] autonomous transactions

On Thu, Oct 6, 2016 at 5:56 AM, Simon Riggs wrote: > Just to point out that I've actually written this approach already. > The patch is available, Autonomous Subtransactions. > We discussed it in Ottawa and it was rejected. (I thought Robert was > there, but Serge and Tom

Re: [HACKERS] autonomous transactions

On 06/10/16 11:56, Simon Riggs wrote: > > * The labelling "Autonomous Transaction" is a simple coat of paint, > which can easily be transferred to a better implementation if one > comes. If one doesn't then its better to have something than nothing. > So I suggest we commit Background

Re: [HACKERS] autonomous transactions

On 7 September 2016 at 20:46, Robert Haas wrote: > On Sat, Sep 3, 2016 at 7:09 AM, Simon Riggs wrote: >> On 2 September 2016 at 09:45, Robert Haas wrote: >>> On Wed, Aug 31, 2016 at 7:20 AM, Peter Eisentraut >>>

Re: [HACKERS] autonomous transactions

On 9/3/16 9:08 AM, Serge Rielau wrote: > Interestingly, despite being supported in PL/SQL on nested BEGIN END blocks, > we nearly exclusively see AT’s covering the entire function or trigger. Oracle only supports an entire PL/SQL function to be declared autonomous. But it was pretty easy in my

Re: [HACKERS] autonomous transactions

On 8/31/16 9:11 AM, Craig Ringer wrote: > Peter, you mention "Oracle-style autonomous transaction blocks". > > What are the semantics to be expected of those with regards to: > > - Accessing objects exclusively locked by the outer xact or where the > requested lockmode conflicts with a lock held

Re: [HACKERS] autonomous transactions

On 8/31/16 8:46 AM, Greg Stark wrote: > I'm surprised by the background worker. I had envisioned autonomous > transactions being implemented by allowing a process to reserve a > second entry in PGPROC with the same pid. Or perhaps save its existing > information in a separate pgproc slot (or stack

Re: [HACKERS] autonomous transactions

On 8/31/16 12:38 AM, Jaime Casanova wrote: > On 30 August 2016 at 20:50, Peter Eisentraut > wrote: >> >> - Patches to PL/pgSQL to implement Oracle-style autonomous transaction >> blocks: >> >> AS $$ >> DECLARE >> PRAGMA AUTONOMOUS_TRANSACTION; >> BEGIN >> FOR

Re: [HACKERS] autonomous transactions

On Tue, Sep 13, 2016 at 5:06 PM, Petr Jelinek wrote: > I mostly agree. I think if this was called something like background > transactions it might be better. It's definitely useful functionality but > the naming is clearly contentious. It won't stop people using it for same

Re: [HACKERS] autonomous transactions

On 13/09/16 22:24, Robert Haas wrote: On Wed, Sep 7, 2016 at 9:14 PM, Craig Ringer wrote: That's probably going to be one of the smaller costs. Doing this with bgworkers won't be cheap, but you need to consider the alternative. Factoring out all

Re: [HACKERS] autonomous transactions

On Wed, Sep 7, 2016 at 9:14 PM, Craig Ringer wrote: > That's probably going to be one of the smaller costs. Doing this with > bgworkers won't be cheap, but you need to consider the alternative. > Factoring out all transaction-specific data currently stored in or >

Re: [HACKERS] autonomous transactions

On 8 Sep. 2016 1:38 pm, "Andres Freund" wrote: > > I kind of dislike this approach for a different reason than already > mentioned in this thread: Namely it's not re-usable for implementing > streaming logical replication of large transaction, i.e. allow to decode > & apply

Re: [HACKERS] autonomous transactions

Hi, On 2016-08-30 21:50:05 -0400, Peter Eisentraut wrote: > I would like to propose the attached patch implementing autonomous > transactions for discussion and review. > > This work was mostly inspired by the discussion about pg_background a > while back [0]. It seemed that most people liked

Re: [HACKERS] autonomous transactions

On 8 September 2016 at 08:18, Tsunakawa, Takayuki wrote: > From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Craig Ringer >> Of course, if we could decrease the startup cost of a bgworker > >> For this use in

Re: [HACKERS] autonomous transactions

From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Craig Ringer > Of course, if we could decrease the startup cost of a bgworker For this use in autonomous tx's we could probably pool workers. Or at least lazily terminate them so that the loop

Re: [HACKERS] autonomous transactions

On 8 Sep. 2016 3:47 am, "Robert Haas" wrote: > > Of course, if we could decrease the startup cost of a bgworker For this use in autonomous tx's we could probably pool workers. Or at least lazily terminate them so that the loop cases work better by re-using an existing

Re: [HACKERS] autonomous transactions

On Sat, Sep 3, 2016 at 7:09 AM, Simon Riggs wrote: > On 2 September 2016 at 09:45, Robert Haas wrote: >> On Wed, Aug 31, 2016 at 7:20 AM, Peter Eisentraut >> wrote: >>> I would like to propose the attached patch

Re: [HACKERS] autonomous transactions

On 3 Sep. 2016 20:27, "Greg Stark" wrote: > > Well using a separate process also requires rewriting locking and > deadlock detection since a reasonable user might expect that second > process to have access to data locked in their current transaction. The user is going to hit

Re: [HACKERS] autonomous transactions

> On Sep 3, 2016, at 5:25 AM, Greg Stark wrote: > > On Sat, Sep 3, 2016 at 12:09 PM, Simon Riggs wrote: >> So doing autonomous transactions inside a single backend doesn't gain >> you very much, yet it is an enormously invasive patch to do it that >> way,

Re: [HACKERS] autonomous transactions

On Sat, Sep 3, 2016 at 12:09 PM, Simon Riggs wrote: > So doing autonomous transactions inside a single backend doesn't gain > you very much, yet it is an enormously invasive patch to do it that > way, not least because it requires you to rewrite locking and > deadlocks to

Re: [HACKERS] autonomous transactions

On 2 September 2016 at 09:45, Robert Haas wrote: > On Wed, Aug 31, 2016 at 7:20 AM, Peter Eisentraut > wrote: >> I would like to propose the attached patch implementing autonomous >> transactions for discussion and review. > > I'm pretty

Re: [HACKERS] autonomous transactions

On 9/2/16 3:45 AM, Robert Haas wrote: So my suggestion is that you pursue the work but change the name. That might make the plpgsql issues significantly easier to deal with as well, by making it very explicit that you're doing something with a completely separate connection. That would make

Re: [HACKERS] autonomous transactions

On Wed, Aug 31, 2016 at 7:20 AM, Peter Eisentraut wrote: > I would like to propose the attached patch implementing autonomous > transactions for discussion and review. I'm pretty skeptical of this approach. Like Greg Stark, Serge Rielau, and Constantin Pan, I

Re: [HACKERS] autonomous transactions

On Thu, Sep 1, 2016 at 8:38 PM, Andres Freund wrote: > > I'm not convinced this makes much sense. All FDWs, dblink etc. already > allow you do stuff outside of a transaction. You as a DBA can prevent FDWs from being used and dblink is an extension that you don't have to

Re: [HACKERS] autonomous transactions

On 2016-08-31 06:10:31 +0200, Joel Jacobson wrote: > This is important if you as a caller function want to be sure none of > the work made by anything called down the stack gets committed. > That is, if you as a caller decide to rollback, e.g. by raising an > exception, and you want to be sure

Re: [HACKERS] autonomous transactions

On Wed, Aug 31, 2016 at 6:22 PM, Simon Riggs wrote: > On 31 August 2016 at 14:09, Joel Jacobson wrote: >> My idea on how to deal with this would be to mark the function to be >> "AUTONOMOUS" similar to how a function is marked to be "PARALLEL >> SAFE", >>

Re: [HACKERS] autonomous transactions

On Thu, Sep 1, 2016 at 12:12 AM, Vik Fearing wrote: > Part of what people want this for is to audit what people *try* to do. > We can already audit what they've actually done. > > With your solution, we still wouldn't know when an unauthorized attempt > to do something

Re: [HACKERS] autonomous transactions

On Wed, 31 Aug 2016 14:46:30 +0100 Greg Stark wrote: > On Wed, Aug 31, 2016 at 2:50 AM, Peter Eisentraut > wrote: > > - A API interface to open a "connection" to a background worker, run > > queries, get results: AutonomousSessionStart(), > >

Re: [HACKERS] autonomous transactions

On 08/31/2016 03:09 PM, Joel Jacobson wrote: > On Wed, Aug 31, 2016 at 6:41 AM, Jaime Casanova > wrote: >> >> On 30 August 2016 at 23:10, Joel Jacobson wrote: >>> >>> There should be a way to within the session and/or txn permanently >>> block

Re: [HACKERS] autonomous transactions

> On Aug 31, 2016, at 6:46 AM, Greg Stark wrote: > > Using a background worker mean that the autonomous transaction can't > access any state from the process memory. Parameters in plpgsql are a > symptom of this but I suspect there will be others. What happens if a > statement

Re: [HACKERS] autonomous transactions

On Wed, Aug 31, 2016 at 3:11 PM, Craig Ringer wrote: > > I suspect that there'll be way too much code that relies on stashing > xact-scoped stuff in globals for that to be viable. Caches alone. > Peter will be able to explain more, I'm sure. > > We'd probably need a new

Re: [HACKERS] autonomous transactions

On 31 August 2016 at 14:09, Joel Jacobson wrote: > On Wed, Aug 31, 2016 at 6:41 AM, Jaime Casanova > wrote: >> >> On 30 August 2016 at 23:10, Joel Jacobson wrote: >> > >> > There should be a way to within the session and/or txn

Re: [HACKERS] autonomous transactions

On 31/08/16 16:11, Craig Ringer wrote: On 31 August 2016 at 21:46, Greg Stark wrote: On Wed, Aug 31, 2016 at 2:50 AM, Peter Eisentraut wrote: - A API interface to open a "connection" to a background worker, run queries, get results:

Re: [HACKERS] autonomous transactions

On 31 August 2016 at 21:46, Greg Stark wrote: > On Wed, Aug 31, 2016 at 2:50 AM, Peter Eisentraut > wrote: >> - A API interface to open a "connection" to a background worker, run >> queries, get results: AutonomousSessionStart(),

Re: [HACKERS] autonomous transactions

On Wed, Aug 31, 2016 at 2:50 AM, Peter Eisentraut wrote: > - A API interface to open a "connection" to a background worker, run > queries, get results: AutonomousSessionStart(), AutonomousSessionEnd(), > AutonomousSessionExecute(), etc. The communication happens

Re: [HACKERS] autonomous transactions

2016-08-31 15:09 GMT+02:00 Joel Jacobson : > On Wed, Aug 31, 2016 at 6:41 AM, Jaime Casanova > wrote: > > > > On 30 August 2016 at 23:10, Joel Jacobson wrote: > > > > > > There should be a way to within the session and/or txn

Re: [HACKERS] autonomous transactions

On Wed, Aug 31, 2016 at 6:41 AM, Jaime Casanova wrote: > > On 30 August 2016 at 23:10, Joel Jacobson wrote: > > > > There should be a way to within the session and/or txn permanently > > block autonomous transactions. > > > > This will defeat one

Re: [HACKERS] autonomous transactions

On 30 August 2016 at 20:50, Peter Eisentraut wrote: > > - Patches to PL/pgSQL to implement Oracle-style autonomous transaction > blocks: > > AS $$ > DECLARE > PRAGMA AUTONOMOUS_TRANSACTION; > BEGIN > FOR i IN 0..9 LOOP > START TRANSACTION; > INSERT

Re: [HACKERS] autonomous transactions

On 30 August 2016 at 23:10, Joel Jacobson wrote: > > There should be a way to within the session and/or txn permanently > block autonomous transactions. > This will defeat one of the use cases of autonomous transactions: auditing > > Coding conventions, rules and discipline

Re: [HACKERS] autonomous transactions

I would love to see autonomous transactions in core. I just have one major concern, but thankfully it's easily addressed. There should be a way to within the session and/or txn permanently block autonomous transactions. This is important if you as a caller function want to be sure none of the

[HACKERS] autonomous transactions

I would like to propose the attached patch implementing autonomous transactions for discussion and review. This work was mostly inspired by the discussion about pg_background a while back [0]. It seemed that most people liked the idea of having something like that, but couldn't perhaps agree on

Re: [HACKERS] autonomous transactions

Robert Haas robertmh...@gmail.com writes: One thing that strikes me (maybe this is obvious) is that the execution of the main transaction and the autonomous transaction are not interleaved: it's a stack. So in terms of globals and stuff, assuming you knew which things needed to be updated,

Re: [HACKERS] autonomous transactions

On Thu, Sep 16, 2010 at 5:19 AM, Dimitri Fontaine dfonta...@hi-media.com wrote: Robert Haas robertmh...@gmail.com writes: One thing that strikes me (maybe this is obvious) is that the execution of the main transaction and the autonomous transaction are not interleaved: it's a stack.  So in

Re: [HACKERS] autonomous transactions

Robert Haas robertmh...@gmail.com writes: I plan to reserve judgment on the best way of managing the relevant state until such time as someone has gone to the trouble of identifying what state that is. The really fundamental problem here is that you never will be able to identify all such

Re: [HACKERS] autonomous transactions

Robert Haas wrote: On Thu, Sep 16, 2010 at 5:19 AM, Dimitri Fontaine dfonta...@hi-media.com wrote: I think they call that dynamic scope, in advanced programming language. I guess that's calling for a quote of Greenspun's Tenth Rule: Any sufficiently complicated C or Fortran program contains

[HACKERS] autonomous transactions (was Re: TODO note)

Robert Haas wrote: On Wed, Sep 15, 2010 at 3:37 AM, Colin 't Hart colinth...@gmail.com wrote: I note that the implementation of tab completion for SET TRANSACTION in PSQL could benefit from the implementation of autonomous transactions (also TODO). I think it's safe to say that if we ever

Re: [HACKERS] autonomous transactions (was Re: TODO note)

On Wed, Sep 15, 2010 at 2:32 PM, Darren Duncan dar...@darrenduncan.net wrote: The point being, the answer to how to implement autonomous transactions could be as simple as, do the same thing as how you manage multiple concurrent client sessions, more or less.  If each client gets its own

Re: [HACKERS] autonomous transactions (was Re: TODO note)

Robert Haas wrote: On Wed, Sep 15, 2010 at 2:32 PM, Darren Duncan dar...@darrenduncan.net wrote: The point being, the answer to how to implement autonomous transactions could be as simple as, do the same thing as how you manage multiple concurrent client sessions, more or less. If each client

Re: [HACKERS] autonomous transactions (was Re: TODO note)

Excerpts from Robert Haas's message of mié sep 15 14:57:29 -0400 2010: I guess so, but the devil is in the details. I suspect that we don't actually want to fork a new backend for every autonomous transactions. That would be pretty expensive, and we already have an expensive way of

Re: [HACKERS] autonomous transactions (was Re: TODO note)

On Wed, Sep 15, 2010 at 6:21 PM, Alvaro Herrera alvhe...@commandprompt.com wrote: Excerpts from Robert Haas's message of mié sep 15 14:57:29 -0400 2010: I guess so, but the devil is in the details.  I suspect that we don't actually want to fork a new backend for every autonomous transactions.

Re: [HACKERS] autonomous transactions

All, Added to TODO: * Add anonymous transactions http://archives.postgresql.org/pgsql-hackers/2008-01/msg00893.php IMHO, autonomous transactions should be part of a package with a spec-compliant CREATE PROCEDURE statement.That is, the difference between PROCEDURES and FUNCTIONS

Re: [HACKERS] autonomous transactions

Josh Berkus escribió: All, Added to TODO: * Add anonymous transactions http://archives.postgresql.org/pgsql-hackers/2008-01/msg00893.php IMHO, autonomous transactions should be part of a package with a spec-compliant CREATE PROCEDURE statement. IMHO we should try to get both things

Re: [HACKERS] autonomous transactions

Simon Riggs wrote: On Tue, 2008-01-22 at 20:53 +0100, Pavel Stehule wrote: Agreed. I think Pavel Stehule was doing some experiments with them, I don't know if he got anywhere. I did only first research. Any hack is possible - you can stack current transaction, but real

Re: [HACKERS] autonomous transactions

Bruce Momjian wrote: Plus I think we'd be able to improve the code for CREATE INDEX under HOT, and probably a few other wrinkly bits of code. Added to TODO: * Add anonymous transactions http://archives.postgresql.org/pgsql-hackers/2008-01/msg00893.php Sorry, updated to Add

Re: [HACKERS] autonomous transactions

On Wed, Jan 23, 2008 at 05:50:02PM -0500, Tom Lane wrote: Simon Riggs [EMAIL PROTECTED] writes: From looking at how Oracle does them, autonomous transactions are completely independent of the transaction that originates them -- they take a new database snapshot. This means that uncommitted

Re: [HACKERS] autonomous transactions

On Wed, Jan 23, 2008 at 05:50:02PM -0500, Tom Lane wrote: Simon Riggs [EMAIL PROTECTED] writes: From looking at how Oracle does them, autonomous transactions are completely independent of the transaction that originates them -- they take a new database snapshot. This means that

Re: [HACKERS] autonomous transactions

On Jan 25, 2008, at 7:27 AM, Decibel! wrote: On Wed, Jan 23, 2008 at 05:50:02PM -0500, Tom Lane wrote: Simon Riggs [EMAIL PROTECTED] writes: From looking at how Oracle does them, autonomous transactions are completely independent of the transaction that originates them -- they take a new

Re: [HACKERS] autonomous transactions

On Tuesday 22 January 2008 11:02, Roberts, Jon wrote: I really needed this functionality in PostgreSQL. A common use for autonomous transactions is error logging. I want to log sqlerrm in a function and raise an exception so the calling application knows there is an error and I have it

Re: [HACKERS] autonomous transactions

On Tue, 2008-01-22 at 20:53 +0100, Pavel Stehule wrote: Agreed. I think Pavel Stehule was doing some experiments with them, I don't know if he got anywhere. I did only first research. Any hack is possible - you can stack current transaction, but real implementation needs similar work

Re: [HACKERS] autonomous transactions

On Tue, 2008-01-22 at 20:53 +0100, Pavel Stehule wrote: And there is most important question about data visibility - is autonomous transaction independent on main transaction (isolation)? From looking at how Oracle does them, autonomous transactions are completely independent of the transaction

Re: [HACKERS] autonomous transactions

On 23/01/2008, Simon Riggs [EMAIL PROTECTED] wrote: On Tue, 2008-01-22 at 20:53 +0100, Pavel Stehule wrote: Agreed. I think Pavel Stehule was doing some experiments with them, I don't know if he got anywhere. I did only first research. Any hack is possible - you can stack

Re: [HACKERS] autonomous transactions

Neil Conway [EMAIL PROTECTED] writes: On Tue, 2008-01-22 at 20:53 +0100, Pavel Stehule wrote: And there is most important question about data visibility - is autonomous transaction independent on main transaction (isolation)? From looking at how Oracle does them, autonomous transactions are

Re: [HACKERS] autonomous transactions

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

Re: [HACKERS] autonomous transactions

On Wed, 2008-01-23 at 00:26 -0800, Neil Conway wrote: On Tue, 2008-01-22 at 20:53 +0100, Pavel Stehule wrote: And there is most important question about data visibility - is autonomous transaction independent on main transaction (isolation)? From looking at how Oracle does them, autonomous

Re: [HACKERS] autonomous transactions

Gokulakannan Somasundaram escribió: The Audit transaction, which is a autonomous transaction need not catch any error and resume the outer transaction. What if the logging fails, say because you forgot to create the audit table? -- Alvaro Herrera

Re: [HACKERS] autonomous transactions

On Wed, 2008-01-23 at 09:30 +, Gregory Stark wrote: I think the hard part would be error handling. You have to be able to catch any errors and resume the outer transaction. I agree that you'd need to do this, but I don't follow why it would be particularly difficult. You essentially have a

Re: [HACKERS] autonomous transactions

Simon Riggs [EMAIL PROTECTED] writes: From looking at how Oracle does them, autonomous transactions are completely independent of the transaction that originates them -- they take a new database snapshot. This means that uncommitted changes in the originating transaction are not visible to the

Re: [HACKERS] autonomous transactions

On Jan 24, 2008 2:46 AM, Alvaro Herrera [EMAIL PROTECTED] wrote: Gokulakannan Somasundaram escribió: The Audit transaction, which is a autonomous transaction need not catch any error and resume the outer transaction. What if the logging fails, say because you forgot to create the audit

Re: [HACKERS] autonomous transactions

On Jan 23, 2008 10:06 PM, Gokulakannan Somasundaram [EMAIL PROTECTED] wrote: On Jan 24, 2008 2:46 AM, Alvaro Herrera [EMAIL PROTECTED] wrote: The Audit transaction, which is a autonomous transaction need not catch any error and resume the outer transaction. What if the logging fails,

[HACKERS] autonomous transactions

I really needed this functionality in PostgreSQL. A common use for autonomous transactions is error logging. I want to log sqlerrm in a function and raise an exception so the calling application knows there is an error and I have it logged to a table. I figured out a way to hack an

Re: [HACKERS] autonomous transactions

On Tue, 2008-01-22 at 10:02 -0600, Roberts, Jon wrote: Maybe someone could enhance this concept to include it with the core database to provide autonomous transactions. I agree that autonomous transactions would be useful, but doing them via dblink is a kludge. If we're going to include

Re: [HACKERS] autonomous transactions

Neil Conway wrote: On Tue, 2008-01-22 at 10:02 -0600, Roberts, Jon wrote: Maybe someone could enhance this concept to include it with the core database to provide autonomous transactions. I agree that autonomous transactions would be useful, but doing them via dblink is a kludge. If we're

Re: [HACKERS] autonomous transactions

On Tue, 2008-01-22 at 10:02 -0600, Roberts, Jon wrote: Maybe someone could enhance this concept to include it with the core database to provide autonomous transactions. I agree that autonomous transactions would be useful, but doing them via dblink is a kludge. Kludge or hack but I

Re: [HACKERS] autonomous transactions

Agreed. I think Pavel Stehule was doing some experiments with them, I don't know if he got anywhere. I did only first research. Any hack is possible - you can stack current transaction, but real implementation needs similar work like nested transaction :( and it is too low level for me. And