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
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
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
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
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
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
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
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
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
>
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
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
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
Hello
regress tests fails:
plancache... ok
limit... ok
plpgsql ... ok
copy2... ok
temp ... FAILED
domain ... ok
rangefuncs ... ok
pr
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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.
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
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
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
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
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
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
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
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.
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
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
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
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
43 matches
Mail list logo
