On 01 July 2014 12:00, Amit Kapila Wrote:
On Tue, Jul 1, 2014 at 11:46 AM, Rajeev rastogi
rajeev.rast...@huawei.commailto: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
On Thu, Jul 3, 2014 at 12:03 PM, Rajeev rastogi rajeev.rast...@huawei.com
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:
On 30 June 2014 22:50, Pavel Stehule Wrote:
2014-06-30 12:38 GMT+02:00 Abhijit Menon-Sen
a...@2ndquadrant.commailto: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
2014-07-01 8:16 GMT+02:00 Rajeev rastogi rajeev.rast...@huawei.com:
On 30 June 2014 22:50, Pavel Stehule Wrote:
2014-06-30 12:38 GMT+02:00 Abhijit Menon-Sen a...@2ndquadrant.com:
If I understand correctly, the design of this patch has already been
considered earlier and rejected. So I
On Tue, Jul 1, 2014 at 11:46 AM, Rajeev rastogi 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
rejected but yes there were few feedback/ concern, which I had
2014-07-01 8:29 GMT+02:00 Amit Kapila amit.kapil...@gmail.com:
On Tue, Jul 1, 2014 at 11:46 AM, Rajeev rastogi 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
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 should be
2014-07-01 10:38 GMT+02:00 Rajeev rastogi rajeev.rast...@huawei.com:
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:
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:
2014-06-30 12:38 GMT+02:00 Abhijit Menon-Sen 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 related message.
?
Regards
Pavel
-- Abhijit
Hello
regress tests fails:
plancache... ok
limit... ok
plpgsql ... ok
copy2... ok
temp ... FAILED
domain ... ok
rangefuncs ... ok
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
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 lines
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:
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 defined to
On 7 April 2014 05:06, Rajeev rastogi rajeev.rast...@huawei.com 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
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 these
On Wed, Apr 9, 2014 at 11:03 AM, Rajeev rastogi
rajeev.rast...@huawei.comwrote:
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
On 04/09/2014 08:44 AM, Pavan Deolasee wrote:
On Wed, Apr 9, 2014 at 11:03 AM, Rajeev rastogi
rajeev.rast...@huawei.com mailto:rajeev.rast...@huawei.com wrote:
Though autonomous transaction uses mixed approach of
sub-transaction as well as main
transaction, transaction state of
On 04/09/2014 02:44 PM, Pavan Deolasee wrote:
On Wed, Apr 9, 2014 at 11:03 AM, Rajeev rastogi
rajeev.rast...@huawei.com mailto:rajeev.rast...@huawei.com wrote:
Though autonomous transaction uses mixed approach of sub-transaction
as well as main
transaction, transaction state
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 Wed, Apr 9, 2014 at 12:24 AM, Rajeev rastogi
rajeev.rast...@huawei.com 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
Robert Haas robertmh...@gmail.com writes:
On Wed, Apr 9, 2014 at 12:24 AM, Rajeev rastogi
rajeev.rast...@huawei.com 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
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 top
On Thu, Apr 10, 2014 at 10:44 AM, Rajeev rastogi
rajeev.rast...@huawei.comwrote:
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
On Mon, Apr 7, 2014 at 12:06 AM, Rajeev rastogi
rajeev.rast...@huawei.com 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
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
On Tue, Apr 8, 2014 at 2:43 PM, Alvaro Herrera alvhe...@2ndquadrant.com 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
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.
Robert Haas robertmh...@gmail.com 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,
On 2014-04-08 16:13:21 -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com 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
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.
Yes
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.
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 rajeev.rast...@huawei.com:
I would like to propose “Autonomous Transaction”
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 behind
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
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 logic behind
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. I
2014-04-07 11:59 GMT+02:00 Rajeev rastogi rajeev.rast...@huawei.com:
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
On Mon, Apr 7, 2014 at 3:41 PM, Pavel Stehule pavel.steh...@gmail.comwrote:
2014-04-07 11:59 GMT+02:00 Rajeev rastogi rajeev.rast...@huawei.com:
On 07 April 2014 12:12, Pavel Stehule wrote:
+1 for feature
Thanks
-1 for Oracle syntax - it is hardly inconsistent with Postgres
We
On 2014-04-07 15:46:42 +0530, Atri Sharma wrote:
On Mon, Apr 7, 2014 at 3:41 PM, Pavel Stehule pavel.steh...@gmail.comwrote:
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
2014-04-07 12:16 GMT+02:00 Atri Sharma atri.j...@gmail.com:
On Mon, Apr 7, 2014 at 3:41 PM, Pavel Stehule pavel.steh...@gmail.comwrote:
2014-04-07 11:59 GMT+02:00 Rajeev rastogi rajeev.rast...@huawei.com:
On 07 April 2014 12:12, Pavel Stehule wrote:
+1 for feature
Thanks
-1
43 matches
Mail list logo
