On 1 March 2017 at 16:05, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
>> On 2/28/17 08:17, Tom Lane wrote:
>>> I do not really see how this would ever get past the compatibility
>>> problems that forced us to give up on server-side autocommit years ago.
>
>> I think it's different because it's not a global setting, it's only a
>> behavior you select explicitly when you start a transaction block.
>
> Yeah, that's the same it-won't-affect-you-if-you-don't-use-it argument
> that we heard for server-side autocommit-off.
This is a frequently requested feature and I think we should push
ahead with it in the next cycle.
We're the World's Most Advanced Open Source Database, so a new
transaction feature fits in with our goals.
> I don't buy it.
> I can think of two reasons even without any caffeine:
>
> 1. The argument for this is mostly, if not entirely, "application
> compatibility". But it won't succeed at providing that if every
> BEGIN has to be spelled differently than it would be on other DBMSes.
> Therefore there is going to be enormous pressure to allow enabling
> the feature through a GUC, or some other environment-level way,
> and as soon as we do that we've lost.
We already use GUCs for various other transaction level features and
they work just fine.
What we need is a feature that works the way other DBMS do, as an
option. If it should be desirable.
I do accept there are problems and we do have some experience of those problems.
> 2. The proposed feature would affect the internal operation of PL
> functions, so that those would need to become bulletproof against
> being invoked in either operating environment. Likewise, all sorts
> of intermediate tools like connection poolers would no doubt be broken
> if they don't know about this and support both modes. (We would have
> to start by fixing postgres_fdw and dblink, for instance.)
>
> In short, you can't make fundamental changes in transactional behavior
> without enormous breakage. That was the lesson we learned from the
> autocommit fiasco and I do not believe that it's inapplicable here.
I think the point we should take from Tom's comments is...
a) This feature won't be a replacement for PostgreSQL's default
behaviour, at least not in any short/medium term.
b) If we get this feature, about 80% of the work will be fixing all
the small breakages that happen with other tools, plugins etc.. So it
is no small task. If accepted this would be a major feature and will
take much work.
If we want this in Postgres11 then we must have a fully working patch
by start of Sept 2017, plus some analysis of all of the various
breakage points we are expecting to see. So lets do the analysis, so
we know how deep the mud is before we decide to walk through it.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services