Re: [HACKERS] Autonomous Transaction (WIP)

2014-07-03 Thread Amit Kapila
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)

2014-07-02 Thread Rajeev rastogi
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 Thread Pavel Stehule
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)

2014-07-01 Thread 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 >Are these notes still valid? >* Why autonomous transaction shoul

Re: [HACKERS] Autonomous Transaction (WIP)

2014-06-30 Thread Pavel Stehule
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)

2014-06-30 Thread 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 were few feedback/ concern, which I had clarified. Also some

Re: [HACKERS] Autonomous Transaction (WIP)

2014-06-30 Thread Pavel Stehule
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)

2014-06-30 Thread Rajeev rastogi
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 Thread Pavel Stehule
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)

2014-06-30 Thread 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? -- 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)

2014-06-24 Thread Pavel Stehule
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)

2014-06-24 Thread Pavel Stehule
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)

2014-06-24 Thread Pavel Stehule
Hello regress tests fails: plancache... ok limit... ok plpgsql ... ok copy2... ok temp ... FAILED domain ... ok rangefuncs ... ok pr

Re: [HACKERS] Autonomous Transaction (WIP)

2014-06-16 Thread Alvaro Herrera
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)

2014-04-14 Thread Rajeev rastogi
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)

2014-04-14 Thread Simon Riggs
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)

2014-04-10 Thread Rajeev rastogi
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)

2014-04-10 Thread Rajeev rastogi
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)

2014-04-09 Thread Pavan Deolasee
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)

2014-04-09 Thread Rajeev rastogi
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)

2014-04-09 Thread Tom Lane
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)

2014-04-09 Thread Robert Haas
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)

2014-04-09 Thread Heikki Linnakangas
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)

2014-04-08 Thread Craig Ringer
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)

2014-04-08 Thread Hannu Krosing
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)

2014-04-08 Thread Pavan Deolasee
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)

2014-04-08 Thread Rajeev rastogi
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)

2014-04-08 Thread Rajeev rastogi
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)

2014-04-08 Thread Andres Freund
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)

2014-04-08 Thread Tom Lane
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)

2014-04-08 Thread Andres Freund
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)

2014-04-08 Thread Robert Haas
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)

2014-04-08 Thread Alvaro Herrera
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)

2014-04-08 Thread Greg Stark
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 Thread Pavel Stehule
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)

2014-04-07 Thread Andres Freund
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)

2014-04-07 Thread 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 hardly inconsistent with Postgres >> >> We can discuss and come

Re: [HACKERS] Autonomous Transaction (WIP)

2014-04-07 Thread Pavel Stehule
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)

2014-04-07 Thread 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 transactions should be used everywhere - not only in plpgsql Yes you are right.

Re: [HACKERS] Autonomous Transaction (WIP)

2014-04-07 Thread Rajeev rastogi
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)

2014-04-07 Thread Ian Barwick
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)

2014-04-06 Thread Craig Ringer
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)

2014-04-06 Thread Pavel Stehule
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