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
Greg Copeland [EMAIL PROTECTED] 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
Well, that's a different issue. ;)
I initially wanted to get feedback to see if anyone else thought the
concept might hold some merit.
I take it from your answer you think it might...but are scratching your
head wondering exactly what it entails...
Greg
On Wed, 2002-08-14 at 22:47, Tom Lane
On Wed, Aug 14, 2002 at 10:15:32PM -0500, Greg Copeland wrote:
Reading about the pgmonitor thread and mention of gborg made me wonder
about replication and ready ability to uniformly monitor it. Just as
pg_stat* tables exist to allow for statistic gathering and monitoring in
a uniform
On Thu, 2002-08-15 at 09:47, Andrew Sullivan wrote:
On Wed, Aug 14, 2002 at 10:15:32PM -0500, Greg Copeland wrote:
That way, no matter what replication method/tool is being used, as long
as it conforms to the defined replication interfaces, generic monitoring
tools can be used to keep an
On Thu, 2002-08-15 at 09:53, Neil Conway wrote:
That's exactly what I was going to say -- I'd prefer that any
interested parties concentrate on producing a *really good*
replication implementation, which might eventually be integrated into
PostgreSQL itself.
Producing a generic API for
As I said -- I don't really see the need for a bunch of replication
implementations, and therefore I don't see the need for a generic API
to make the whole mess (slightly) more manageable.
I see. So the intension of the core developers is to have one and only
one replication solution?
Greg
Greg Copeland [EMAIL PROTECTED] writes:
As I said -- I don't really see the need for a bunch of replication
implementations, and therefore I don't see the need for a generic API
to make the whole mess (slightly) more manageable.
I see. So the intension of the core developers is to have
On Thu, 2002-08-15 at 13:18, Neil Conway wrote:
That said, I _personally_ don't see the need for more than one or two
replication implementations. You might need more than one if you
wanted to do both lazy and eager replication, for example. But you
certainly don't need 5 or 6 or however many
--=-QQHYShMlxI2BY71i6NiO
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
As I said -- I don't really see the need for a bunch of replication
implementations, and therefore I don't see the need for a generic API
to make the whole mess (slightly) more manageable.
Neil Conway [EMAIL PROTECTED] writes:
Greg Copeland [EMAIL PROTECTED] writes:
I see. So the intension of the core developers is to have one and only
one replication solution?
Not being a core developer, I can't comment on their intentions.
Well, I am, but I'm only speaking for myself here:
Reading about the pgmonitor thread and mention of gborg made me wonder
about replication and ready ability to uniformly monitor it. Just as
pg_stat* tables exist to allow for statistic gathering and monitoring in
a uniform fashion, it occurred to me that a predefined set of views
and/or tables
Greg Copeland [EMAIL PROTECTED] writes:
... it occurred to me that a predefined set of views
and/or tables for all replication implementations may be worthwhile.
Do we understand replication well enough to define such a set of views?
I sure don't ...
regards, tom lane
13 matches
Mail list logo
