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 -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers