On Thu, 2002-08-15 at 15:36, Tom Lane wrote: > Well, I am, but I'm only speaking for myself here: >
Fair enough.
> I think there is room for several replication solutions for Postgres
> (three or four, maybe).
If the ideal solution count is merely one with a maybe on two then I
tend to concur that any specification along these lines would *mostly*
be a waste. On the other hand, if we can count three or more possible
replication solutions, IMHO, there seemingly would be merit is providing
some sort of defacto monitoring interface.
Seems the current difficulty is forecasting the future in this regard.
Perhaps other core developers would care to chime in and share their
vision?
> CVS tree. So assuming that the Postgres-R project gets to the point
> of usefulness, I'd vote in favor of integrating it. On the other hand,
I guess I should ask. Do the developers foresee immediate usability
from this project or are we looking at something that's a year+ away? I
don't think I have a problem helping guide what could be an interim
solution if the interim window were large enough. In theory, monitoring
tools developed between now and the closing of the window could largely
continue to function without change. That, of course, assumes that even
the end-run solutions would implement the interface as well.
The return on such a concept is that it allows generic monitoring tools
to mature while providing value now and in the future. The end result
should be a stronger, more powerful tool base which matures while other
technologies are still being developed.
Another question along this line is, once something rolls into a core
position, does that obsolete all other existing implementations or
merely become the defacto in a bag of solutions? Tom seems to hint at
the later. If the answer is the former then that seemingly argues not
to worry about this...unless the window for usefulness and/or inclusion
is rather large.
> As for the point at hand: I'm fairly dubious that a common monitoring
> API will be very useful, considering how different the possible
Well, all replication scenarios have a lot in common. They should,
after all, they are all doing the same thing. Since the different
strategies for accomplishing replication are well understood, it seems
well within reason to assume that someone can put their brain around
this.
I can also imagine that the specification includes requirements as well
as optional facilities. Certainly capability queries would further iron
out any gaps between differing solutions/implementations.
> replication approaches are. If Greg can prove me wrong, fine. But
> I don't want to see us artificially constraining replication solutions
> by insisting that they meet some prespecified API.
Hmmm. I'm not sure how it would act as a constraining force. To me,
this implies that any such specification would fail to evolve and could
not be revised based on feedback. IMO, most specifications are regarded
as living documents. While I can see that some specifications are set
in stone, I certainly am not so bold as to assert my crystal ball even
came with batteries. ;) That is, I assume some level of revision to an
initial specification would be required following real-world use.
Regards,
Greg Copeland
signature.asc
Description: This is a digitally signed message part
