Re: autonomous transactions
От | Greg Stark |
---|---|
Тема | Re: autonomous transactions |
Дата | |
Msg-id | CAM-w4HNniRP_bgPyVqj0LTm1YCR+CiL-vgWxogRe55JvJzPB8g@mail.gmail.com обсуждение исходный текст |
Ответ на | autonomous transactions (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>) |
Ответы |
Re: autonomous transactions
Re: autonomous transactions Re: autonomous transactions Re: autonomous transactions |
Список | pgsql-hackers |
On Wed, Aug 31, 2016 at 2:50 AM, Peter Eisentraut <peter.eisentraut@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? -- greg
В списке pgsql-hackers по дате отправления: