Greg Copeland <greg@copelandconsulting.net> writes:
> I guess I should ask. Do the developers foresee immediate usability
> from [Postgres-R] or are we looking at something that's a year+ away?
Darren Johnson would be the man to answer that, but from what he said
at OSCON it sounded like we'd be seeing something useful by the end of
the year, with all the usual caveats about time actually being available
to work on it.
>> 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,=20
> after all, they are all doing the same thing.
The end goal is approximately the same, but the mechanisms are totally
different, and that means that what you want to monitor is totally
different.
Perhaps the problem is that you're using the wrong word, and that what
you would like to standardize is not monitoring but administrative
functions. For example, I'd classify selecting tables to be replicated
as an admin task. Monitoring to me means something like "how much data
is in the queue to be pushed out to slave X?", which is a question that
already presupposes a heck of a lot about the implementation.
I could agree with a set of guidelines that say stuff like "if your
mechanism is capable of selecting individual tables to replicate,
then here's the preferred way to control that feature." But I'm not
sure that there's enough common functionality for monitoring (in the
above sense) to be worth standardizing.
regards, tom lane
