Re: [HACKERS] Autonomous Transaction is back

On Fri, Sep 11, 2015 at 02:30:53PM -0500, Merlin Moncure wrote: > On Thu, Sep 10, 2015 at 8:39 PM, Noah Misch wrote: > > It's an exceptionally-challenging development project, agreed. So much code > > assumes the 1:1 relationship between backends and top-level transactions. > > I guess I'm being

Re: [HACKERS] Autonomous Transaction is back

On Thu, Sep 10, 2015 at 8:39 PM, Noah Misch wrote: > On Wed, Sep 09, 2015 at 10:04:01AM -0400, Robert Haas wrote: >> On Sun, Sep 6, 2015 at 1:56 AM, Noah Misch wrote: >> > What design principle(s) have you been using to decide how autonomous >> > transactions should behave? >> >> I have to admit

Re: [HACKERS] Autonomous Transaction is back

On Wed, Sep 09, 2015 at 10:04:01AM -0400, Robert Haas wrote: > On Sun, Sep 6, 2015 at 1:56 AM, Noah Misch wrote: > > What design principle(s) have you been using to decide how autonomous > > transactions should behave? > > I have to admit to a complete lack of principle. I'm quite frightened > o

Re: [HACKERS] Autonomous Transaction is back

On Wed, Sep 9, 2015 at 9:04 AM, Robert Haas wrote: > On Sun, Sep 6, 2015 at 1:56 AM, Noah Misch wrote: >> What design principle(s) have you been using to decide how autonomous >> transactions should behave? > > I have to admit to a complete lack of principle. I'm quite frightened > of what this

Re: [HACKERS] Autonomous Transaction is back

On Sun, Sep 6, 2015 at 1:56 AM, Noah Misch wrote: > What design principle(s) have you been using to decide how autonomous > transactions should behave? I have to admit to a complete lack of principle. I'm quite frightened of what this is going to need from the lock manager, and I'm trying to wri

Re: [HACKERS] Autonomous Transaction is back

On Sun, Sep 6, 2015 at 12:56 AM, Noah Misch wrote: > My comments have flowed out of a principle that autonomous transactions shall > have precisely the same semantics as using another backend via dblink. That's what I thought, too. AT is syntax sugar for dblink approach. Syntax and performance a

Re: [HACKERS] Autonomous Transaction is back

On Thu, Sep 03, 2015 at 04:21:55PM -0400, Robert Haas wrote: > On Sat, Aug 22, 2015 at 2:23 AM, Noah Misch wrote: > >> > Can you get away with only looking at tuples though? For example, > >> > what about advisory locks? Table locks? > >> > >> Well, that's an interesting question. Can we get aw

Re: [HACKERS] Autonomous Transaction is back

On Sat, Aug 22, 2015 at 2:23 AM, Noah Misch wrote: >> > Can you get away with only looking at tuples though? For example, >> > what about advisory locks? Table locks? >> >> Well, that's an interesting question. Can we get away with regarding >> those things as non-conflicting, as between the pa

Re: [HACKERS] Autonomous Transaction is back

On Fri, Aug 21, 2015 at 10:06:44AM -0400, Robert Haas wrote: > On Tue, Aug 18, 2015 at 3:06 PM, Merlin Moncure wrote: > > On Tue, Aug 18, 2015 at 8:17 AM, Robert Haas wrote: > >> On Sat, Aug 15, 2015 at 6:47 PM, Noah Misch wrote: > >>> [1] That's not to say it must use the shmem lock structures

Re: [HACKERS] Autonomous Transaction is back

On Tue, Aug 18, 2015 at 3:06 PM, Merlin Moncure wrote: > On Tue, Aug 18, 2015 at 8:17 AM, Robert Haas wrote: >> On Sat, Aug 15, 2015 at 6:47 PM, Noah Misch wrote: >>> CREATE TABLE t (c) AS SELECT 1; >>> BEGIN; >>> UPDATE t SET c = 2 WHERE c = 1; >>> BEGIN_AUTONOMOUS; >>> UPDATE t SET c = 3 WHERE

Re: [HACKERS] Autonomous Transaction is back

On 18 August 2015 21:18, Robert Haas Wrote: >This footnote goes to my point. > >It seems clear to me that having the autonomous transaction "see" the >effects of the outer uncommitted transaction is a recipe for trouble. >If the autonomous transaction updates a row and commits, and the outer >tran

Re: [HACKERS] Autonomous Transaction is back

On Tue, Aug 18, 2015 at 8:17 AM, Robert Haas wrote: > On Sat, Aug 15, 2015 at 6:47 PM, Noah Misch wrote: >> CREATE TABLE t (c) AS SELECT 1; >> BEGIN; >> UPDATE t SET c = 2 WHERE c = 1; >> BEGIN_AUTONOMOUS; >> UPDATE t SET c = 3 WHERE c = 1; >> UPDATE t SET c = 4 WHERE c = 2; >> COMMIT_AUTONOMOUS;

Re: [HACKERS] Autonomous Transaction is back

On Sat, Aug 15, 2015 at 6:47 PM, Noah Misch wrote: > CREATE TABLE t (c) AS SELECT 1; > BEGIN; > UPDATE t SET c = 2 WHERE c = 1; > BEGIN_AUTONOMOUS; > UPDATE t SET c = 3 WHERE c = 1; > UPDATE t SET c = 4 WHERE c = 2; > COMMIT_AUTONOMOUS; > ROLLBACK; > > If you replace the autonomous transaction wit

Re: [HACKERS] Autonomous Transaction is back

Noah Misch wrote: > > > If the autonomous transaction can interact with uncommitted > > > work in a way that other backends could not, crazy things happen when the > > > autonomous transaction commits and the suspended transaction aborts: > > > > > > CREATE TABLE t (c) AS SELECT 1; > > > BEGIN; > >

Re: [HACKERS] Autonomous Transaction is back

On Sat, Aug 15, 2015 at 10:20:55PM -0300, Alvaro Herrera wrote: > Noah Misch wrote: > > > In today's scenarios, the later query cannot commit unless the suspended > > query > > also commits. (Changing that is the raison d'être of autonomous > > transactions.) If the autonomous transaction can i

Re: [HACKERS] Autonomous Transaction is back

Noah Misch wrote: > In today's scenarios, the later query cannot commit unless the suspended query > also commits. (Changing that is the raison d'être of autonomous > transactions.) If the autonomous transaction can interact with uncommitted > work in a way that other backends could not, crazy t

Re: [HACKERS] Autonomous Transaction is back

On Fri, Aug 07, 2015 at 11:26:08AM -0400, Robert Haas wrote: > On Thu, Aug 6, 2015 at 11:04 PM, Merlin Moncure wrote: > > I don't necessarily disagree with what you're saying, but it's not > > clear to me what the proposed behavior is. Since the AT can commit > > before the outer, ISTM *any* ungr

Re: [HACKERS] Autonomous Transaction is back

On Thu, Aug 6, 2015 at 11:04 PM, Merlin Moncure wrote: > I don't necessarily disagree with what you're saying, but it's not > clear to me what the proposed behavior is. Since the AT can commit > before the outer, ISTM *any* ungranted lock requested by the AT but > held by the outer leads to eithe

Re: [HACKERS] Autonomous Transaction is back

On Thu, Aug 6, 2015 at 4:15 PM, Robert Haas wrote: > On Mon, Aug 3, 2015 at 9:09 AM, Merlin Moncure wrote: >> hm. OK, what's the behavior of: >> >> BEGIN >> UPDATE foo SET x = x + 1 WHERE foo_id = 1; >> >> BEGIN WITH AUTONOMOUS TRANSACTION >> UPDATE foo SET x = x + 1 WHERE foo_id = 1; >>

Re: [HACKERS] Autonomous Transaction is back

On Mon, Aug 3, 2015 at 9:09 AM, Merlin Moncure wrote: > hm. OK, what's the behavior of: > > BEGIN > UPDATE foo SET x = x + 1 WHERE foo_id = 1; > > BEGIN WITH AUTONOMOUS TRANSACTION > UPDATE foo SET x = x + 1 WHERE foo_id = 1; > END; > > RAISE EXCEPTION ...; > EXCEPTION ... > > END; S

Re: [HACKERS] Autonomous Transaction is back

On Tue, Aug 4, 2015 at 4:12 AM, Rajeev rastogi wrote: > On 03 August 2015 18:40, Merlin Moncure [mailto:mmonc...@gmail.com] Wrote: >>On Sun, Aug 2, 2015 at 11:37 PM, Rajeev rastogi >> wrote: >>> On 31 July 2015 23:10, Robert Haas Wrote: I think we're going entirely down the wrong path here. W

Re: [HACKERS] Autonomous Transaction is back

On 03 August 2015 18:40, Merlin Moncure [mailto:mmonc...@gmail.com] Wrote: >On Sun, Aug 2, 2015 at 11:37 PM, Rajeev rastogi > wrote: >> On 31 July 2015 23:10, Robert Haas Wrote: >>>I think we're going entirely down the wrong path here. Why is it ever >useful for a backend's lock requests to confli

Re: [HACKERS] Autonomous Transaction is back

On Sun, Aug 2, 2015 at 11:37 PM, Rajeev rastogi wrote: > On 31 July 2015 23:10, Robert Haas Wrote: >>I think we're going entirely down the wrong path here. Why is it ever useful >>for a backend's lock requests to conflict with themselves, even with >>autonomous transactions? That seems like an

Re: [HACKERS] Autonomous Transaction is back

On 31 July 2015 23:10, Robert Haas Wrote: On Tue, Jul 28, 2015 at 6:01 AM, Craig Ringer wrote: >> That should be practical to special-case by maintaining a list of >> parent transaction (virtual?) transaction IDs. Attempts to wait on a >> lock held by any of those should fail immediately. There

Re: [HACKERS] Autonomous Transaction is back

On Tue, Jul 28, 2015 at 6:01 AM, Craig Ringer wrote: > That should be practical to special-case by maintaining a list of > parent transaction (virtual?) transaction IDs. Attempts to wait on a > lock held by any of those should fail immediately. There's no point > waiting for the deadlock detector

Re: [HACKERS] Autonomous Transaction is back

On 28 July 2015 03:21, Josh Berkus Wrote: On 07/27/2015 02:47 AM, Rajeev rastogi wrote: >>> Why have any fixed maximum? >> Since we are planning to have nested autonomous transaction, so it is >> required to have limit on this so that resources can be controlled. >Is there a particular reason w

Re: [HACKERS] Autonomous Transaction is back

On 28 July 2015 15:31, Craig Ringer Wrote: >> 2.It should be allowed to deadlock with master transaction. >We >> need to work-out a solution to avoid deadlock. > >The deadlock case in autonomous tx's is a bit different. > >Assuming you don't intend to allow interleaving, where you can

Re: [HACKERS] Autonomous Transaction is back

On 23 July 2015 at 13:31, Rajeev rastogi wrote: > 1.The autonomous transaction treated as a completely different > transaction from the master transaction. Personally I think that's a lot more useful than having the inner tx able to see the outer tx's uncommitted changes. > 2.

Re: [HACKERS] Autonomous Transaction is back

On Tue, Jul 28, 2015 at 12:56 AM, Josh Berkus wrote: > Ah, ok. The goal of the project is that the writer of X() *cannot* > prevent Y() from writing its data (B1) and committing it. > > One of the primary use cases for ATX is audit triggers. If a function > writer could override ATX and preven

Re: [HACKERS] Autonomous Transaction is back

> Ah, you're missing how commits in ATX are expected to work. Let me > illustrate: > > X ( >Data write A1 >call Y( > Start ATX > Data write B1 > Commit ATX >) >Data write A2 >Exception > ) > > In this workflow, B1 would be committed and persistent. Neith

Re: [HACKERS] Autonomous Transaction is back

2015-07-27 23:59 GMT+02:00 Merlin Moncure : > On Mon, Jul 27, 2015 at 4:41 PM, Joel Jacobson wrote: > > On Fri, Jul 24, 2015 at 9:39 PM, Merlin Moncure > wrote: > >> > >> On Thu, Jul 23, 2015 at 1:49 PM, Josh Berkus wrote: > >> > Batch Jobs: large data-manipulation tasks which need to be broken

Re: [HACKERS] Autonomous Transaction is back

On 7/27/15 6:40 PM, Jim Nasby wrote: On 7/27/15 5:12 PM, Joel Jacobson wrote: Right now, when writing a function, if you raise an exception, you can be sure all writes you have made will be rollbacked, but your caller function might caught the exception and decide to carry on and commit work mad

Re: [HACKERS] Autonomous Transaction is back

On 7/27/15 5:56 PM, Josh Berkus wrote: Can you explain what use case you have where simply telling the staff "if you use ATX without clearing it, you'll be fired" is not sufficient? Possibly there's something we failed to account for in the unconference discussion. That there's no way to enfo

Re: [HACKERS] Autonomous Transaction is back

On 7/27/15 5:12 PM, Joel Jacobson wrote: Right now, when writing a function, if you raise an exception, you can be sure all writes you have made will be rollbacked, but your caller function might caught the exception and decide to carry on and commit work made before your function was called, but

Re: [HACKERS] Autonomous Transaction is back

On 07/27/2015 03:12 PM, Joel Jacobson wrote: > On Mon, Jul 27, 2015 at 11:49 PM, Josh Berkus > wrote: > > Ah, you're missing how commits in ATX are expected to work. Let me > illustrate: > > X ( >Data write A1 >call Y( > Start AT

Re: [HACKERS] Autonomous Transaction is back

On Mon, Jul 27, 2015 at 11:49 PM, Josh Berkus wrote: > Ah, you're missing how commits in ATX are expected to work. Let me > illustrate: > > X ( >Data write A1 >call Y( > Start ATX > Data write B1 > Commit ATX >) >Data write A2 >Exception > ) > > In thi

Re: [HACKERS] Autonomous Transaction is back

On Mon, Jul 27, 2015 at 4:41 PM, Joel Jacobson wrote: > On Fri, Jul 24, 2015 at 9:39 PM, Merlin Moncure wrote: >> >> On Thu, Jul 23, 2015 at 1:49 PM, Josh Berkus wrote: >> > Batch Jobs: large data-manipulation tasks which need to be broken up >> > into segments, with each segment committing sepa

Re: [HACKERS] Autonomous Transaction is back

On 07/27/2015 02:47 AM, Rajeev rastogi wrote: >> Why have any fixed maximum? > Since we are planning to have nested autonomous transaction, so it is > required to have limit on this so that resources can be controlled. Is there a particular reason why this limit wouldn't just be max_stack_depth?

Re: [HACKERS] Autonomous Transaction is back

On 07/27/2015 02:41 PM, Joel Jacobson wrote: > However, we should also add a way for the caller to protect against an > Autonomous Transaction in a function called by the caller. Imagine if > you're the author of function X() and within X() make use of some other > function Y() which has been writt

Re: [HACKERS] Autonomous Transaction is back

On Fri, Jul 24, 2015 at 9:39 PM, Merlin Moncure wrote: > On Thu, Jul 23, 2015 at 1:49 PM, Josh Berkus wrote: > > Batch Jobs: large data-manipulation tasks which need to be broken up > > into segments, with each segment committing separately. Example: > > updating 1 million records in batches of

Re: [HACKERS] Autonomous Transaction is back

On 23 July 2015 21:04, Robert Haas Wrote: On Thu, Jul 23, 2015 at 1:31 AM, Rajeev rastogi wrote: >> 2.It should be allowed to deadlock with master transaction. We >> need to work-out a solution to avoid deadlock. >This sentence seems to contradict itself. I thought the consensus was

Re: [HACKERS] Autonomous Transaction is back

On Thu, Jul 23, 2015 at 1:49 PM, Josh Berkus wrote: > Batch Jobs: large data-manipulation tasks which need to be broken up > into segments, with each segment committing separately. Example: > updating 1 million records in batches of 1000. Autonomous transactions are not a good fit for this case;

Re: [HACKERS] Autonomous Transaction is back

On Thu, Jul 23, 2015 at 11:01 AM, Rajeev rastogi wrote: > After few failed attempt to propose Autonomous transaction earlier. I > along with Simon Riggs would like to propose again but completely different > in approach. > > > > We also had discussion about this feature in last PGCon2015 Unconfe

Re: [HACKERS] Autonomous Transaction is back

On 07/23/2015 12:40 PM, Robert Haas wrote: > That's a problem, but I think it is rather unfair to say that it has > anything to do with autonomous transactions. "Run a procedure without > needing to hold a snapshot" is a completely separate feature request > from "allow autonomous transactions", a

Re: [HACKERS] Autonomous Transaction is back

On Thu, Jul 23, 2015 at 2:49 PM, Josh Berkus wrote: > On 07/23/2015 11:39 AM, Robert Haas wrote: >> On Thu, Jul 23, 2015 at 2:33 PM, Josh Berkus wrote: Requesting for everyone's opinion regarding this based on which we can proceed to enhance/tune/re-write our design. >>> >>> So, one of

Re: [HACKERS] Autonomous Transaction is back

On 07/23/2015 11:39 AM, Robert Haas wrote: > On Thu, Jul 23, 2015 at 2:33 PM, Josh Berkus wrote: >>> Requesting for everyone's opinion regarding this based on which we can >>> proceed to enhance/tune/re-write our design. >> >> So, one of the things which came up during the discussion was advancing

Re: [HACKERS] Autonomous Transaction is back

On Thu, Jul 23, 2015 at 2:33 PM, Josh Berkus wrote: >> Requesting for everyone's opinion regarding this based on which we can >> proceed to enhance/tune/re-write our design. > > So, one of the things which came up during the discussion was advancing > XMIN, which is not important to the audit logg

Re: [HACKERS] Autonomous Transaction is back

> Requesting for everyone's opinion regarding this based on which we can > proceed to enhance/tune/re-write our design. So, one of the things which came up during the discussion was advancing XMIN, which is not important to the audit logging use case, but is very important for the batch job us

Re: [HACKERS] Autonomous Transaction is back

On Thu, Jul 23, 2015 at 1:31 AM, Rajeev rastogi wrote: > 2.It should be allowed to deadlock with master transaction. We > need to work-out a solution to avoid deadlock. This sentence seems to contradict itself. I thought the consensus was that the transaction should NOT conflict with

[HACKERS] Autonomous Transaction is back

After few failed attempt to propose Autonomous transaction earlier. I along with Simon Riggs would like to propose again but completely different in approach. We also had discussion about this feature in last PGCon2015 Unconference Day, those who missed this discussion, please refer

Re: [HACKERS] Autonomous Transaction (WIP)

On Thu, Jul 3, 2014 at 12:03 PM, Rajeev rastogi wrote: > On 01 July 2014 12:00, Amit Kapila Wrote: > >Simon has mentioned that exactly this idea has been rejected at > > >PGCon 2 years back. Please refer that in below mail: > > > http://www.postgresql.org/message-id/bf2827dcce55594c8d7a8f7ffd3ab77

Re: [HACKERS] Autonomous Transaction (WIP)

On 01 July 2014 12:00, Amit Kapila Wrote: >On Tue, Jul 1, 2014 at 11:46 AM, Rajeev rastogi >mailto:rajeev.rast...@huawei.com>> wrote: >> On 30 June 2014 22:50, Pavel Stehule Wrote: >> >I didn't find a related message. >> >? >> >> I think there have been some confusion, the design idea were never

Re: [HACKERS] Autonomous Transaction (WIP)

2014-07-01 10:38 GMT+02:00 Rajeev rastogi : > On 01 July 2014 12:26, Pavel Stehule Wrote: > > > > >>Have you checked the discussion in Developer meeting notes. Please > > >>check the same at below link: > > >> > http://wiki.postgresql.org/wiki/PgCon_2012_Developer_Meeting#Autonomous_Transactions

Re: [HACKERS] Autonomous Transaction (WIP)

On 01 July 2014 12:26, Pavel Stehule Wrote: >>Have you checked the discussion in Developer meeting notes. Please >>check the same at below link: >>http://wiki.postgresql.org/wiki/PgCon_2012_Developer_Meeting#Autonomous_Transactions >Are these notes still valid? >* Why autonomous transaction shoul

Re: [HACKERS] Autonomous Transaction (WIP)

2014-07-01 8:29 GMT+02:00 Amit Kapila : > On Tue, Jul 1, 2014 at 11:46 AM, Rajeev rastogi > wrote: > > On 30 June 2014 22:50, Pavel Stehule Wrote: > > > > >I didn't find a related message. > > >? > > > > I think there have been some confusion, the design idea were never > rejected but yes there w

Re: [HACKERS] Autonomous Transaction (WIP)

On Tue, Jul 1, 2014 at 11:46 AM, Rajeev rastogi wrote: > On 30 June 2014 22:50, Pavel Stehule Wrote: > > >I didn't find a related message. > >? > > I think there have been some confusion, the design idea were never rejected but yes there were few feedback/ concern, which I had clarified. Also some

Re: [HACKERS] Autonomous Transaction (WIP)

2014-07-01 8:16 GMT+02:00 Rajeev rastogi : > On 30 June 2014 22:50, Pavel Stehule Wrote: > > 2014-06-30 12:38 GMT+02:00 Abhijit Menon-Sen : > > >>If I understand correctly, the design of this patch has already been > >>considered earlier and rejected. So I guess the patch should also be > >>marke

Re: [HACKERS] Autonomous Transaction (WIP)

On 30 June 2014 22:50, Pavel Stehule Wrote: 2014-06-30 12:38 GMT+02:00 Abhijit Menon-Sen mailto:a...@2ndquadrant.com>>: >>If I understand correctly, the design of this patch has already been >>considered earlier and rejected. So I guess the patch should also be >>marked rejected? >I didn't find a

Re: [HACKERS] Autonomous Transaction (WIP)

2014-06-30 12:38 GMT+02:00 Abhijit Menon-Sen : > If I understand correctly, the design of this patch has already been > considered earlier and rejected. So I guess the patch should also be > marked rejected? > I didn't find a related message. ? Regards Pavel > > -- Abhijit >

Re: [HACKERS] Autonomous Transaction (WIP)

If I understand correctly, the design of this patch has already been considered earlier and rejected. So I guess the patch should also be marked rejected? -- Abhijit -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql

Re: [HACKERS] Autonomous Transaction (WIP)

Hello There are lot of unnecessary block over one statement in code + if ((inAutoX) && (chunk == events->head) && ((char *)event < afterTriggers->events_stack[my_level].tailfree)) + { + continue; + } + and there a few too long line

Re: [HACKERS] Autonomous Transaction (WIP)

postgres=# select version(); version - PostgreSQL 9.5devel on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.8.2 20131212 (Red Hat 4.8.2-7), 64-bit (1 row) 2014-06-24 18:39 GMT+02

Re: [HACKERS] Autonomous Transaction (WIP)

Hello regress tests fails: plancache... ok limit... ok plpgsql ... ok copy2... ok temp ... FAILED domain ... ok rangefuncs ... ok pr

Re: [HACKERS] Autonomous Transaction (WIP)

What's the status of this patch? -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref

Re: [HACKERS] Autonomous Transaction (WIP)

On 14 April 2014 20:10, Simon Riggs wrote: >>Autonomous Transaction Storage: >>As for main transaction, structure PGXACT is used to store main transactions, >>which are created in shared memory of size: >> (Number of process)*sizeof(struct PGXACT) >>Similarly a new structure will be def

Re: [HACKERS] Autonomous Transaction (WIP)

On 7 April 2014 05:06, Rajeev rastogi wrote: > *Autonomous Transaction Storage:* > > As for main transaction, structure PGXACT is used to store main > transactions, which are created in shared memory of size: > > (Number of process)*sizeof(struct PGXACT) > > Similarly a n

Re: [HACKERS] Autonomous Transaction (WIP)

On 09 April 2014 21:25, Robert Haas Wrote: > >> > Deadlock Detection: > >> I'm not sure how this would work out internally > > In order to resolve deadlock, two member variable will be created in > the structure PROLOCK: > > Bitmask for lock types currently held by autonomous > transaction

Re: [HACKERS] Autonomous Transaction (WIP)

On 10 April 2014 11:18, Pavan Deolasee Wrote: >>I could think of few global variables like transaction properties >>related(i.e. read-only mode, isolation level etc). As I plan to keep >>transaction properties of autonomous transaction same as main transaction, so >>there is no need to have the

Re: [HACKERS] Autonomous Transaction (WIP)

On Thu, Apr 10, 2014 at 10:44 AM, Rajeev rastogi wrote: > On 09 April 2014 12:14, Pavan Deolasee Wrote: > > >Whenever I was asked to have a look at implementing this feature, I > always wondered about the great amount of global state that a backend > maintains which is normally tied to a single

Re: [HACKERS] Autonomous Transaction (WIP)

On 09 April 2014 12:14, Pavan Deolasee Wrote: >Whenever I was asked to have a look at implementing this feature, I always >wondered about the great amount of global state that a backend maintains which >is normally tied to a single top transaction. Since AT will have same >characteristics as a

Re: [HACKERS] Autonomous Transaction (WIP)

Robert Haas writes: > On Wed, Apr 9, 2014 at 12:24 AM, Rajeev rastogi > wrote: >> Now when we grant the lock to particular transaction, depending on type of >> transaction, bit >> Mask will be set for either holdMaskByAutoTx or holdMaskByNormalTx. >> Similar when lock is ungranted, corresponding

Re: [HACKERS] Autonomous Transaction (WIP)

On Wed, Apr 9, 2014 at 12:24 AM, Rajeev rastogi wrote: >> > Deadlock Detection: >> I'm not sure how this would work out internally > In order to resolve deadlock, two member variable will be created in the > structure PROLOCK: > Bitmask for lock types currently held by autonomous transact

Re: [HACKERS] Autonomous Transaction (WIP)

On 04/09/2014 09:55 AM, Hannu Krosing wrote: This would be greatly simplified if we can accept the restriction that there is only single snapshot per backend (not per transaction). To me this seems a completely sensible restriction. Huh? In Read committed mode, every query within a transaction

Re: [HACKERS] Autonomous Transaction (WIP)

On 04/09/2014 02:44 PM, Pavan Deolasee wrote: > On Wed, Apr 9, 2014 at 11:03 AM, Rajeev rastogi > mailto:rajeev.rast...@huawei.com>> wrote: > > > Though autonomous transaction uses mixed approach of sub-transaction > as well as main > transaction, transaction state of autonomous trans

Re: [HACKERS] Autonomous Transaction (WIP)

On 04/09/2014 08:44 AM, Pavan Deolasee wrote: > On Wed, Apr 9, 2014 at 11:03 AM, Rajeev rastogi > mailto:rajeev.rast...@huawei.com>> wrote: > > > Though autonomous transaction uses mixed approach of > sub-transaction as well as main > transaction, transaction state of autonomous transac

Re: [HACKERS] Autonomous Transaction (WIP)

On Wed, Apr 9, 2014 at 11:03 AM, Rajeev rastogi wrote: > > Though autonomous transaction uses mixed approach of sub-transaction as > well as main > transaction, transaction state of autonomous transaction is handled > independently. > > Whenever I was asked to have a look at implementing this feat

Re: [HACKERS] Autonomous Transaction (WIP)

On 09 April 2014 01:43, Tom Lane Wrote: > > I'm also pretty unconvinced that multiple PGPROCs is the right way to > > go. First, PGPROCs have a bunch of state in them that is assumed to > > exist once per backend. We might find pretty substantial code churn > > there if we try to go change that.

Re: [HACKERS] Autonomous Transaction (WIP)

On 09 April 2014 01:09, Rover Haas Wrote: > I'm also pretty unconvinced that multiple PGPROCs is the right way to > go. First, PGPROCs have a bunch of state in them that is assumed to > exist once per backend. We might find pretty substantial code churn > there if we try to go change that. Y

Re: [HACKERS] Autonomous Transaction (WIP)

On 2014-04-08 16:13:21 -0400, Tom Lane wrote: > Robert Haas writes: > > I'm also pretty unconvinced that multiple PGPROCs is the right way to > > go. First, PGPROCs have a bunch of state in them that is assumed to > > exist once per backend. We might find pretty substantial code churn > > there

Re: [HACKERS] Autonomous Transaction (WIP)

Robert Haas writes: > I'm also pretty unconvinced that multiple PGPROCs is the right way to > go. First, PGPROCs have a bunch of state in them that is assumed to > exist once per backend. We might find pretty substantial code churn > there if we try to go change that. Second, why do other backe

Re: [HACKERS] Autonomous Transaction (WIP)

On 2014-04-08 15:39:18 -0400, Robert Haas wrote: > I'm also pretty unconvinced that multiple PGPROCs is the right way to > go. First, PGPROCs have a bunch of state in them that is assumed to > exist once per backend. We might find pretty substantial code churn > there if we try to go change that.

Re: [HACKERS] Autonomous Transaction (WIP)

On Tue, Apr 8, 2014 at 2:43 PM, Alvaro Herrera wrote: > Greg Stark wrote: >> If the autonomous transaction is actually a separate procarray entry >> (which I suspect it would have to be, much like prepared transactions >> and the dblink connections which are commonly used to kludge >> autonomous t

Re: [HACKERS] Autonomous Transaction (WIP)

Greg Stark wrote: > If the autonomous transaction is actually a separate procarray entry > (which I suspect it would have to be, much like prepared transactions > and the dblink connections which are commonly used to kludge > autonomous transactions) then this should be fairly painless. If you > i

Re: [HACKERS] Autonomous Transaction (WIP)

On Mon, Apr 7, 2014 at 12:06 AM, Rajeev rastogi wrote: > > Deadlock Detection: > > It is possible that the main or upper autonomous transaction has taken a lock > on some resource, which might be required by lower autonomous transaction. If > it happens so then deadlock will occur. So in order t

Re: [HACKERS] Autonomous Transaction (WIP)

2014-04-07 12:16 GMT+02:00 Atri Sharma : > > > > On Mon, Apr 7, 2014 at 3:41 PM, Pavel Stehule wrote: > >> >> >> >> 2014-04-07 11:59 GMT+02:00 Rajeev rastogi : >> >> On 07 April 2014 12:12, Pavel Stehule wrote: >>> >>> >+1 for feature >>> >>> Thanks >>> >>> >>> >>> >-1 for Oracle syntax - it is

Re: [HACKERS] Autonomous Transaction (WIP)

On 2014-04-07 15:46:42 +0530, Atri Sharma wrote: > On Mon, Apr 7, 2014 at 3:41 PM, Pavel Stehule wrote: > I am missing something here, but how does making it a subtransaction break > consistency? Isnt that what should actually be happening so that the > autonomous transaction's changes are actually

Re: [HACKERS] Autonomous Transaction (WIP)

On Mon, Apr 7, 2014 at 3:41 PM, Pavel Stehule wrote: > > > > 2014-04-07 11:59 GMT+02:00 Rajeev rastogi : > > On 07 April 2014 12:12, Pavel Stehule wrote: >> >> >+1 for feature >> >> Thanks >> >> >> >> >-1 for Oracle syntax - it is hardly inconsistent with Postgres >> >> We can discuss and come

Re: [HACKERS] Autonomous Transaction (WIP)

2014-04-07 11:59 GMT+02:00 Rajeev rastogi : > On 07 April 2014 12:12, Pavel Stehule wrote: > > >+1 for feature > > Thanks > > > > >-1 for Oracle syntax - it is hardly inconsistent with Postgres > > We can discuss and come out with the syntax based on everyone agreement. > > >Autonomous transacti

Re: [HACKERS] Autonomous Transaction (WIP)

On 07 April 2014 12:12, Pavel Stehule wrote: >+1 for feature Thanks >-1 for Oracle syntax - it is hardly inconsistent with Postgres We can discuss and come out with the syntax based on everyone agreement. >Autonomous transactions should be used everywhere - not only in plpgsql Yes you are right.

Re: [HACKERS] Autonomous Transaction (WIP)

On 07 April 2014 12:20, Craig Ringer > > > Syntax to create autonomous transaction can be as: > > > > */PRAGMA AUTONOMOUS TRANSACTION;/* > > Wouldn't you want to use SET TRANSACTION for this? > > Or a suffix on BEGIN, like BEGIN AUTONOMOUS TRANSACTION ? > > What's the lo

Re: [HACKERS] Autonomous Transaction (WIP)

On 07/04/14 15:50, Craig Ringer wrote: On 04/07/2014 12:06 PM, Rajeev rastogi wrote: Syntax to create autonomous transaction can be as: */PRAGMA AUTONOMOUS TRANSACTION;/* Wouldn't you want to use SET TRANSACTION for this? Or a suffix on BEGIN, like BEGIN AUTONOMOUS

Re: [HACKERS] Autonomous Transaction (WIP)

On 04/07/2014 12:06 PM, Rajeev rastogi wrote: > Syntax to create autonomous transaction can be as: > > */PRAGMA AUTONOMOUS TRANSACTION;/* Wouldn't you want to use SET TRANSACTION for this? Or a suffix on BEGIN, like BEGIN AUTONOMOUS TRANSACTION ? What's the logic behin

Re: [HACKERS] Autonomous Transaction (WIP)

Hello +1 for feature -1 for Oracle syntax - it is hardly inconsistent with Postgres Autonomous transactions should be used everywhere - not only in plpgsql Regards Pavel 2014-04-07 6:06 GMT+02:00 Rajeev rastogi : > I would like to propose “Autonomous Transaction” feature for 9.5. > Details

Re: [HACKERS] Autonomous transaction

On Tue, Apr 13, 2010 at 8:24 PM, Bruce Momjian wrote: >> I think it would be really useful, though, for users and maybe even >> for system internals.  Working out the semantics is a challenge, but >> not an insurmountable one, I think. > > Yea, it is going to feel like a ship with a leaky hull, so

Re: [HACKERS] Autonomous transaction

Robert Haas wrote: > On Tue, Apr 13, 2010 at 8:01 PM, Bruce Momjian wrote: > > 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. > > I think it would be really useful,

Re: [HACKERS] Autonomous transaction

On Tue, Apr 13, 2010 at 8:01 PM, Bruce Momjian wrote: > 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. I think it would be really useful, though, for users and maybe eve

Re: [HACKERS] Autonomous transaction

p...@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 s

Re: [HACKERS] Autonomous transaction

udson -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

Re: [HACKERS] Autonomous transaction

Loïc Vaumerel 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 k

Re: [HACKERS] Autonomous transaction

On Sun, Apr 4, 2010 at 10:26 AM, Loïc Vaumerel 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. >

  1   2   >