On Sun, Sep 6, 2015 at 12:56 AM, Noah Misch <n...@leadboat.com> wrote: > My comments have flowed out of a principle that autonomous transactions shall > have precisely the same semantics as using another backend via dblink.
That's what I thought, too. AT is syntax sugar for dblink approach. Syntax and performance aside, I think the only way dblink style AT could be improved would be to have: 1) better cancel handling, especially cancel child when parent cancels (this is a major headache with dblink) 2) automatic rejection of acquire attempts by child on exclusive assets held by parent #2 is what we've been discussing, but I'm pretty confused. Most especially I'm not clear on whether parent and children share a pid or have unique pid. If pids are unique as in dblink, #2 could be done via a query assuming you have a way of identifying child transactions in pg_stat_activity. The discussion has suggested that the pid is shared, which I found odd but took on faith. I'm also wondering if we need syntax to handle synchronous vs asynchronous execution of the AT (the latter of which is only possible with a separate PID, I think). merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
