Re: Standard replication interface?
От | Tom Lane |
---|---|
Тема | Re: Standard replication interface? |
Дата | |
Msg-id | 7619.1029508526@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Standard replication interface? (Greg Copeland <greg@CopelandConsulting.Net>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: