Re: [HACKERS] autonomous transactions

2017-02-01 Thread Michael Paquier
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

2017-01-07 Thread Andrey Borodin
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

2016-10-12 Thread Petr Jelinek
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 Thread Pavel Stehule
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

2016-10-11 Thread 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 at 21:27, Robert Haas wrote: I think we should

Re: [HACKERS] autonomous transactions

2016-10-11 Thread Pavel Stehule
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

2016-10-11 Thread 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 background transactions and call them >>> background transactions. That

Re: [HACKERS] autonomous transactions

2016-10-10 Thread Merlin Moncure
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

2016-10-09 Thread Andres Freund
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

2016-10-09 Thread Robert Haas
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

2016-10-06 Thread Simon Riggs
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

2016-10-06 Thread Robert Haas
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

2016-10-06 Thread Petr Jelinek
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

2016-10-06 Thread Simon Riggs
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

2016-09-15 Thread Peter Eisentraut
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

2016-09-15 Thread Peter Eisentraut
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

2016-09-15 Thread Peter Eisentraut
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

2016-09-15 Thread Peter Eisentraut
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

2016-09-13 Thread Robert Haas
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

2016-09-13 Thread Petr Jelinek
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

2016-09-13 Thread Robert Haas
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

2016-09-08 Thread Craig Ringer
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

2016-09-07 Thread Andres Freund
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

2016-09-07 Thread Craig Ringer
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

2016-09-07 Thread Tsunakawa, Takayuki
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

2016-09-07 Thread Craig Ringer
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

2016-09-07 Thread Robert Haas
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

2016-09-03 Thread Craig Ringer
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

2016-09-03 Thread Serge Rielau
> 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

2016-09-03 Thread Greg Stark
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

2016-09-03 Thread Simon Riggs
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

2016-09-02 Thread Jim Nasby
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

2016-09-02 Thread Robert Haas
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

2016-09-02 Thread Joel Jacobson
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

2016-09-01 Thread Andres Freund
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

2016-09-01 Thread Joel Jacobson
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

2016-09-01 Thread Joel Jacobson
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

2016-09-01 Thread Constantin S. Pan
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

2016-08-31 Thread Vik Fearing
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

2016-08-31 Thread Serge Rielau
> 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

2016-08-31 Thread Greg Stark
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

2016-08-31 Thread Simon Riggs
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

2016-08-31 Thread Petr Jelinek
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

2016-08-31 Thread Craig Ringer
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

2016-08-31 Thread Greg Stark
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 Thread Pavel Stehule
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

2016-08-31 Thread 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 permanently > > block autonomous transactions. > > > > This will defeat one

Re: [HACKERS] autonomous transactions

2016-08-30 Thread Jaime Casanova
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

2016-08-30 Thread Jaime Casanova
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

2016-08-30 Thread Joel Jacobson
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

Re: [HACKERS] autonomous transactions

2010-09-16 Thread Dimitri Fontaine
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

2010-09-16 Thread Robert Haas
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

2010-09-16 Thread Tom Lane
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

2010-09-16 Thread Darren Duncan
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

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

2010-09-15 Thread Robert Haas
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)

2010-09-15 Thread Darren Duncan
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)

2010-09-15 Thread Alvaro Herrera
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)

2010-09-15 Thread Robert Haas
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

2008-01-30 Thread Josh Berkus
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

2008-01-30 Thread Alvaro Herrera
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

2008-01-29 Thread Bruce Momjian
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

2008-01-29 Thread Bruce Momjian
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

2008-01-28 Thread Decibel!
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

2008-01-28 Thread Roberts, Jon
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

2008-01-28 Thread Hans-Juergen Schoenig
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

2008-01-24 Thread Robert Treat
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

2008-01-23 Thread Simon Riggs
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

2008-01-23 Thread Neil Conway
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

2008-01-23 Thread Pavel Stehule
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

2008-01-23 Thread Gregory Stark
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

2008-01-23 Thread Gokulakannan Somasundaram
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

2008-01-23 Thread Simon Riggs
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

2008-01-23 Thread Alvaro Herrera
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

2008-01-23 Thread Neil Conway
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

2008-01-23 Thread Tom Lane
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

2008-01-23 Thread Gokulakannan Somasundaram
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

2008-01-23 Thread Jonah H. Harris
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,

Re: [HACKERS] autonomous transactions

2008-01-22 Thread Neil Conway
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

2008-01-22 Thread Alvaro Herrera
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

2008-01-22 Thread Roberts, Jon
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

2008-01-22 Thread Pavel Stehule
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