On 01/03/16 18:18, Konstantin Knizhnik wrote:
On 01.03.2016 19:03, Robert Haas wrote:
On Tue, Mar 1, 2016 at 10:37 AM, Bruce Momjian <br...@momjian.us> wrote:
On Tue, Mar 1, 2016 at 10:19:45AM -0500, Robert Haas wrote:
Two reasons:
1. There is no ideal implementation of DTM which will fit all
possible needs
and be efficient for all clusters.
Hmm, what is the reasoning behind that statement? I mean, it is
certainly true that there are some places where we have decided that
one-size-fits-all is not the right approach. Indexing, for example.
Uh, is that even true of indexing? While the plug-in nature of indexing
allows for easier development and testing, does anyone create plug-in
indexing that isn't shipped by us? I thought WAL support was something
that prevented external indexing solutions from working.
True. There is an API, though, and having pluggable WAL support seems
desirable too. At the same time, I don't think we know of anyone
maintaining a non-core index AM ... and there are probably good
reasons for that. We end up revising the index AM API pretty
regularly every time somebody wants to do something new, so it's not
really a stable API that extensions can just tap into. I suspect that
a transaction manager API would end up similarly situated.
IMHO non-stable API is better than lack of API.
Just because it makes it possible to implement features in modular way.
And refactoring of API is not so difficult thing...
Since this thread heavily discusses the XTM, I have question about the
XTM as proposed because one thing is very unclear to me - what happens
when user changes the XTM plugin on the server? I didn't see any xid
handover API which makes me wonder if changes of a plugin (or for
example failure to load previously used plugin due to admin error) will
send server to similar situation as xid wraparound.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
