On 2016-10-06 10:56:34 +0100, Simon Riggs wrote:
> On 7 September 2016 at 20:46, Robert Haas <robertmh...@gmail.com> wrote:
> > On Sat, Sep 3, 2016 at 7:09 AM, Simon Riggs <si...@2ndquadrant.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.


Andres Freund

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to