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 ? 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'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. We'd probably need a new transaction data object that everything xact-scoped hangs off, so we can pass it everywhere or swap it out of some global. The mechanical refactoring alone would be pretty scary, not to mention the complexity of actually identifying all the less obvious places that need changing. Consider invalidation callbacks. They're always "fun", and so simple to get right.... -- Craig Ringer 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
