On 01 July 2014 12:00, Amit Kapila Wrote:
>On Tue, Jul 1, 2014 at 11:46 AM, Rajeev rastogi
>> 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
>> of the other concerns are already fixed in latest patch.
>Simon has mentioned that exactly this idea has been rejected at
>PGCon 2 years back. Please refer that in below mail:
>As far as I can see, you never came back with the different solution.
Yeah right. So for this I tried to search archived mails to get the details
about the discussion but I could not find anything regarding design.
So I am not sure how shall I make my solution different from earlier as earlier
solution is not accessible to me. Any help regarding this will be really great
help to me.
Also from the current Autonomous transaction discussion thread (including
I have summarized all important feedbacks as mentioned below along with the
1. Pavel Stehule (07-04-2014): -1 for Oracle syntax - it is hardly
inconsistent with Postgres
Changed the syntax to “START AUTONOMOUS TRANSACTION”
2. Pavan (10-04-2014): Making autonomous transaction properties
independent of main transaction.
Made all properties of autonomous transaction (including read-only) independent
from main transaction except isolation level, which I did not find very useful
to keep different. But others opinion is different then we can make this
property also independent.
3. Alvaro Herrarta (09-04-2014): Autonomous transaction to have their own
separate proc entry.
This was concluded to not have separate proc entry for autonomous transaction
and same concluded.
4. Tom Lane (09-04-2014): The point being that you need to change both
pg_subtrans and pg_clog to make that state transition.
This is handled for autonomous transaction.
5. Robert Haas (09-04-2014): Not in favour of current design related to
"maintaining lockmask for autonomous transaction".
I had replied for this mail regarding why this design is kept but still if
design for this part is not acceptable, then I can rework to make it better. In
order to do so I would be very happy to have more discussion to get concrete
feedback and direction to improve this.
6. Tom Lane (09-04-2014): no justification for distinguishing normal and
autonomous transactions at this level (locking level).
I had replied this also earlier. Reason for distinguishing at this level is to
handle any kind of deadlock possibility between main and autonomous
transaction. Deadlock handling between main and autonomous transaction was one
of the requirement discussed at PGCon 2012 as part of autonomous transaction
discussion. Please let me know if I am missing something in this.
All of the above mentioned changes are included in latest patch shared.
Please let me know if I have missed any other important points from the earlier
discussion, I would like to address that also.
>Have you checked the discussion in Developer meeting notes. Please
>check the same at below link:
From the discussion, I am able to make out two important points:
1. Main transaction and autonomous transaction should be independent and
This is already included in our latest patch.
2. Utility commands like VACUUM and CREATE INDEX CONCURRENTLY should be
able to work from autonomous transaction.
Both of the above mentioned utility commands are not supported even inside the
main transaction. So it is not working within autonomous transaction.
Any opinion about this?
Please let me know if I have missed any points from the link given.
>> So I wanted to have this patch in commitfest application, so that we can
>> have a healthy discussion and rectify all the issues.
>> But now I see that this patch has already been moved to rejected category,
>> which will put break on further review.
>I believe ideally this patch should have been marked as
>"Returned with feedback" as you already got a feedback long
>back and never come up with solution for same.
Since this patch is very big and complex, it is better we continue discussing
from the first CommitFest itself so that we can get ample time to share
everyone’s opinion and then address all possible issue.
Any Opinions/Suggestions are welcome. Also let me know if I have missed
Thanks and Regards,
Kumar Rajeev Rastogi