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. Second, why do other backends
> > really need to know about our ATs? As far as I can see, if other
> > backends see the AT as a subtransaction of our top-level transaction
> > up until it actually commits, that ought to be just fine.
>
> If we can make it work like that, sure. I'm a bit worried about how
> you'd decouple a subtransaction and commit it atomically ... or if
> that's not atomic, will it create any problems?
Though autonomous transaction uses mixed approach of sub-transaction as well as main
transaction, transaction state of autonomous transaction is handled independently.
So depending on the transaction state of autonomous transaction (for commit TBLOCK_AUTOCOMMIT),
this transaction will be committed. While committing:
1. Commit of record and logging the corresponding WAL happens in the same way as main transaction (except the way
autonomoustransaction and their sub-transaction accessed).This will take care automatically of updating pg_clog also
forautonomous transaction.
2. Also it marks the autonomous transaction finish by setting appropriate fields of MyPgAutonomousXact in similar
manneras done for main transaction.
3. Freeing of all resource and popping out of parent transaction happens in the same way as sub-transaction.
> The point being that
> you need to change both pg_subtrans and pg_clog to make that state
> transition.
Yes I am changing both. But no specific changes were required. During commit and assignment of autonomous transaction,
itis automatically taken care.
Any comment/feedback/doubt are welcome?
Thanks and Regards,
Kumar Rajeev Rastogi