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