On Wed, Feb 24, 2016 at 3:05 PM, Oleg Bartunov <obartunov@gmail.com> wrote: > 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 need > 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 !
