Re: Autonomous Transaction is back - Mailing list pgsql-hackers

From Merlin Moncure
Subject Re: Autonomous Transaction is back
Date
Msg-id CAHyXU0x8X2-iwTzJFzSjRDHR8j2TuK8AwT2kPhJ=8HA+vRGNDw@mail.gmail.com
Whole thread Raw
In response to Re: Autonomous Transaction is back  (Noah Misch <noah@leadboat.com>)
List pgsql-hackers
On Sun, Sep 6, 2015 at 12:56 AM, Noah Misch <noah@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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Odd/undocumented precedence of concatenation operator
Next
From: Julien Rouhaud
Date:
Subject: Re: Allow a per-tablespace effective_io_concurrency setting