Re: autonomous transactions

From: Andres Freund <andres(at)anarazel(dot)de>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: autonomous transactions
Date: 2016-10-09 22:17:02
Message-ID: 20161009221702.rtqgzfqktx6l5wfp@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2016-10-06 10:56:34 +0100, Simon Riggs wrote:
> On 7 September 2016 at 20:46, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> > On Sat, Sep 3, 2016 at 7:09 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> > True. I believe this issue has been discussed before, and I think
> > it's a solvable issue. I believe that an autonomous transaction could
> > be made to appear to the rest of the system (outside the affected
> > backend) as if it were a subtransaction, but then get committed before
> > the containing transaction gets committed. This would avoid needing
> > more PGPROCs (but getting deadlock detection to work is hard).
>
> Just to point out that I've actually written this approach already.
> The patch is available, Autonomous Subtransactions.
> We discussed it in Ottawa and it was rejected. (I thought Robert was
> there, but Serge and Tom definitely were).

Hm, maybe I'm missing something, but don't pretty all of the objections
to that approach also apply to this one, baring some additional changes
required for lock conflict detection?

> We have various approaches... summarised in chronological order of
> their suggestion
>
> 1. Use additional PGXACTs - rejected because it wouldn't provide enough room

Doesn't this approach precisely requires additional PGXACTs in the form
of additional background workers? Plus a full process overhead?

> 2. Use Autonomous SubTransactions - rejected because the semantics are
> different to what we might expect from ATs

Which semantics are fundamentally different? Snapshot visibility seems
fairly trivial to adapt, and so seems locking. In even seems slightly
easier to give a good error message about deadlocking against the main
transaction in this approach.

Greetings,

Andres Freund

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2016-10-09 22:33:35 Re: Relids in upper relations
Previous Message Robert Haas 2016-10-09 22:12:31 Re: [COMMITTERS] pgsql: Remove -Wl,-undefined,dynamic_lookup in macOS build.