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 autonomous transaction and their 
sub-transaction accessed).
        This will take care automatically of updating pg_clog also for 
autonomous transaction.
2.      Also it marks the autonomous transaction finish by setting appropriate 
fields of MyPgAutonomousXact in similar manner as 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, it is automatically taken care. 

Any comment/feedback/doubt are welcome?

Thanks and Regards,
Kumar Rajeev Rastogi








-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to