On 8/31/16 8:46 AM, Greg Stark wrote:
> 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.
There is quite likely room for a feature like that too, but it's not
this one.
> Using a background worker mean that the autonomous transaction can't
> access any state from the process memory.
That is intentional.
Autonomous transactions is actually a misnomer. It's autonomous
sessions. But Oracle names it wrong. Autonomous sessions (or whatever
you want to call them) have their own session state, configuration
parameters, potentially different plugins loaded, different
authorization state, and so on.
> What happens if a
> statement timeout occurs during an autonomous transaction?
Right now not much. ;-) But I think the behavior should be that the
autonomous session is aborted.
> 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?
The same thing that happens if you open a new unrelated database
connection and try to do that.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
