On Wed, 31 Aug 2016 14:46:30 +0100 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. > > 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. > > Using a background worker mean that the autonomous transaction can't > access any state from the process memory. Parameters in plpgsql are a > symptom of this but I suspect there will be others. What happens if a > statement timeout occurs during an autonomous transaction? What > happens if you use a pl language in the autonomous transaction and if > it tries to use non-transactional information such as prepared > statements?
I am trying to implement autonomous transactions that way. I have already implemented suspending and restoring the parent transaction state, at least some of it. The next thing on the plan is the procarray/snapshot stuff. I think we should reuse the same PGPROC for the autonomous transaction, and allocate a stack of PGXACTs for the case of nested autonomous transactions. Solving the more general problem, running multiple concurrent transactions with a single backend, may also be interesting for some users. Autonomous transactions would then be just a use case for that feature. Regards, Constantin Pan Postgres Professional: http://www.postgrespro.com The Russian Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
