Re: autonomous transactions

On Thu, Oct 6, 2016 at 5:56 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> 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).

Where is the patch?

> See other posts in this thread by Serge and Craig to explain why.

I don't think the posts on Craig and Serge explain why that approach
was rejected or would be a bad idea.

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

Of course, a background worker uses a PGXACT too and a lot more, so if
you think extra PGXACTs are bad, you should *really* think background
workers are bad.

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

In what way? I think the questions of how you implement it and what
the semantics are are largely orthogonal questions. To which proposal
is this referring?

> 3. Use background transactions (this thread)

Sure.

> 4. Use pause and resume so we don't use up too many PGXACTs

I don't know what "pause and resume" means.

> * The labelling "Autonomous Transaction" is a simple coat of paint,
> which can easily be transferred to a better implementation if one
> comes. If one doesn't then its better to have something than nothing.
> So I suggest we commit Background Transactions first and then in a
> fairly thin commit, implement Autonomous Transactions on top of it for
> now and if we get a better one, switch it over.

I think we should implement background transactions and call them
background transactions. That allows us to expose additional
functionality which is useful, like the ability to kick something off
and check back later for the results. There's no reason to call it
background transactions and also call it autonomous transactions: one
feature doesn't need two names.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company