> On Sep 3, 2016, at 5:25 AM, Greg Stark <st...@mit.edu> wrote: > > On Sat, Sep 3, 2016 at 12:09 PM, Simon Riggs <si...@2ndquadrant.com> wrote: >> So doing autonomous transactions inside a single backend doesn't gain >> you very much, yet it is an enormously invasive patch to do it that >> way, not least because it requires you to rewrite locking and >> deadlocks to make them work correctly when proc is not 1:1 with xid. >> And as Serge points out it introduces other restrictions that we know >> about now, perhaps more as well. > > Well using a separate process also requires rewriting locking and > deadlock detection since a reasonable user might expect that second > process to have access to data locked in their current transaction.The > plus side is that we're already facing that issue with parallel query > so at least it's something that only has to be solved once instead of > a new problem. I can’t speak for reasonable users, (or persons in fact ;-) But… previous implementations of ATs do fully expect them to deadlock on their parents and not see uncommitted changes. So if one’s goal is to merely match competitors’ behavior then that part is a non issue. I do not recall the single backend approach having been particularly invasive. We managed to do a the 9.4 -> 9.5 merge with little problem despite it.
IMHO, solving the problem of passing variables to and from an AT is required for viability of the feature. How else would the AT know what it’s supposed to do? Starting an AT within a DDL transaction seems a much more narrow use case to me. Interestingly, despite being supported in PL/SQL on nested BEGIN END blocks, we nearly exclusively see AT’s covering the entire function or trigger. This usage property can be used to narrow the scope of variable passing to function parameters. Cheers Serge Rielau salesforce.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
