On 31/08/16 16:11, Craig Ringer wrote:
> On 31 August 2016 at 21:46, Greg Stark <stark@mit.edu> wrote:
>> 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.
>
> 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
>
That would be my question as well.
>
> 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 would expect that in PLs it's handled by them, if you misuse this on C
level that's your problem?
>> 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.
>
I can also see some advantages in bgworker approach. For example it
could be used for "fire and forget" type of interface in the future,
where you return as soon as you send exec and don't care about waiting
for result.
-- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training &
Services
