Re: Autonomous Transaction (WIP)

2014-07-01 8:29 GMT+02:00 Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>:

> On Tue, Jul 1, 2014 at 11:46 AM, Rajeev rastogi <rajeev(dot)rastogi(at)huawei(dot)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 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:
>
> http://www.postgresql.org/message-id/BF2827DCCE55594C8D7A8F7FFD3AB7713DDE136A@SZXEML508-MBX.china.huawei.com
>
> As far as I can see, you never came back with the different solution.
>
> 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 close to functions? We can
implement AT as first step and next step can be implementation of
integration AT to stored procedures.

* When autonomous transaction is independent on parent transaction, then
locks parent and autonomous transaction should be in conflict

I though about integration to PL/pgSQL and I don't think so close
integration between autonomous transaction and procedure is optimal. More
practical is design so autonomous transaction is similar to subtransaction.

Then we can simply wrote some code like

BEGIN
.. some code
WHEN OTHERS THEN
.. I would to write permanently to log
BEGIN AUTONOMOUS
INSERT INTO log VALUES(..);
WHEN OTHERS
RAISE WARNING 'Cannot to write to log ..';
RAISE EXCEPTION ' ...' forward up exception from autonomous
transaction to parent transaction
END
END;

Now I am thinking so PL/SQL design of autonomous transactions is relatively
limited and is not best to follow it.

Regards

Pavel

>
> > 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.
>
> With Regards,
> Amit Kapila.
> EnterpriseDB: http://www.enterprisedb.com
>