<p dir="ltr"><p dir="ltr">On 3 Sep. 2016 20:27, "Greg Stark" <<a href="mailto:stark@mit.edu">stark@mit.edu</a>>
wrote:<br/> ><p dir="ltr">> Well using a separate process also requires rewriting locking and<br /> > deadlock
detectionsince a reasonable user might expect that second<br /> > process to have access to data locked in their
currenttransaction.<p dir="ltr">The user is going to hit some confusing issues.<p dir="ltr">Xact1: alter table... Add
column...<br/> Xact2: inserts data with new format<br /> Xact2: autonomous commits leaving xact1 running<br /> Xact2:
rollback<pdir="ltr">There are similar issues with FKs and and sorts. It isn't limited to schema changes.<p dir="ltr">I
don'tsee how autonomous xacts that inherit parent xact's uncommitted data, locks, etc can ever really be safe. Useful,
butuse at your own (considerable) risk and unlikely to be worth the issues they introduce.<p dir="ltr">If they inherit
locksbut don't see uncommitted data it'd be even worse.<p dir="ltr">See the autonomous commit subxact thread for more
onthese issues.<p dir="ltr">><br /> > Parallel query is currently restricted to read-only queries however.<br />
>Autonomous transactions will certainly need to be read-write so the<br /> > question then is what problems led
tothe restriction in parallel<br /> > query and are they any more tractable with autonomous transactions?<br /><p
dir="ltr">Parallelquery is fairly different because it doesn't have it's own xact. This should mean no need to be able
towait on a separate virtualxid or xid, no need to have their own TransactionID allocated, no complex considerations of
visibilityand most importantly can't commit separately.
