From: | Greg Stark <stark(at)mit(dot)edu> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: autonomous transactions |
Date: | 2016-09-03 12:25:32 |
Message-ID: | CAM-w4HNrNyUaYoc3DWz8ufQKg7e1SROGiSdKpv7FQ-HgMZPEaw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Sep 3, 2016 at 12:09 PM, Simon Riggs <simon(at)2ndquadrant(dot)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.
Parallel query is currently restricted to read-only queries however.
Autonomous transactions will certainly need to be read-write so the
question then is what problems led to the restriction in parallel
query and are they any more tractable with autonomous transactions?
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2016-09-03 12:36:59 | Re: Password identifiers, protocol aging and SCRAM protocol |
Previous Message | Tomas Vondra | 2016-09-03 11:37:40 | Re: Index Onlys Scan for expressions |