On 31/08/16 16:11, Craig Ringer wrote:
On 31 August 2016 at 21:46, Greg Stark <st...@mit.edu> wrote:
On Wed, Aug 31, 2016 at 2:50 AM, Peter Eisentraut
<peter.eisentr...@2ndquadrant.com> wrote:
- A API interface to open a "connection" to a background worker, run
queries, get results: AutonomousSessionStart(), AutonomousSessionEnd(),
AutonomousSessionExecute(), etc. The communication happens using the
client/server protocol.
Peter, you mention "Oracle-style autonomous transaction blocks".
What are the semantics to be expected of those with regards to:
- Accessing objects exclusively locked by the outer xact or where the
requested lockmode conflicts with a lock held by the outer xact
- Visibility of data written by the outer xact
That would be my question as well.
Also, is it intended (outside the plpgsql interface) that the
autonomous xact can proceed concurrently/interleaved with a local
backend xact? i.e. the local backend xact isn't suspended and you're
allowed to do things on the local backend as well? If so, what
handling do you have in mind for deadlocks between the local backend
xact and the bgworker with the autonomous xact? I'd expect the local
backend to always win, killing the autonomous xact every time.
I would expect that in PLs it's handled by them, if you misuse this on C
level that's your problem?
I'm surprised by the background worker. I had envisioned autonomous
transactions being implemented by allowing a process to reserve a
second entry in PGPROC with the same pid. Or perhaps save its existing
information in a separate pgproc slot (or stack of slots) and
restoring it after the autonomous transaction commits.
I suspect that there'll be way too much code that relies on stashing
xact-scoped stuff in globals for that to be viable. Caches alone.
Peter will be able to explain more, I'm sure.
I can also see some advantages in bgworker approach. For example it
could be used for "fire and forget" type of interface in the future,
where you return as soon as you send exec and don't care about waiting
for result.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
