On Fri, Feb 26, 2016 at 3:50 PM, Robert Haas <robertmh...@gmail.com> wrote:
> On Wed, Feb 24, 2016 at 3:05 PM, Oleg Bartunov <obartu...@gmail.com>
> > I already several times pointed, that we need XTM to be able to continue
> > development in different directions, since there is no clear winner.
> > Moreover, I think there is no fits-all solution and while I agree we
> > one built-in in the core, other approaches should have ability to exists
> > without patching.
> I don't think I necessarily agree with that. Transaction management
> is such a fundamental part of the system that I think making it
> pluggable is going to be really hard. I understand that you've done
> several implementations based on your proposed API, and that's good as
> far as it goes, but how do we know that's really going to be general
> enough for what other people might need?
Right now tm is hardcoded and it's doesn't matter "if other people might
need" at all. We at least provide developers ("other people") ability to
work on their implementations and the patch is safe and doesn't sacrifices
anything in core.
> And what makes us think we
> really need multiple transaction managers, anyway?
If you brave enough to say that one tm-fits-all and you are able to teach
existed tm to play well in various clustering environment during
development period, which is short, than probably we don't need multiple
tms. But It's too perfect to believe and practical solution is to let
multiple groups to work on their solutions.
> Even writing one
> good distributed transaction manager seems like a really hard project
> - why would we want to write two or three or five?
again, right now it's simply impossible to any bright person to work on
dtms. It's time to start working on dtm, I believe. The fact you don't
think about distributed transactions support doesn't mean there no "other
people", who has different ideas on postgres future. That's why we propose
this patch, let's play the game !
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company