Hi,
Jeff Davis wrote:
> I think you misunderstand my point.
That may well be. Please keep in mind that I'm not a native English
speaker, thus please speak loud and clear ;-)
> I was talking about replication
> implementations that already exist. They already have patches on the
> backend that are necessary for their solution to work.
Do they? I'm only aware of the GORDA patch. The old Postgres-R patches
are out of date. Sequoia, PgPool and PgPool-II obviously do not need
patches. Slony-II, Postgres-R (8) (mine) as well as PGCluster-II are not
open sourced, yet. And I haven't heard much regarding hooks from any of
the proprietary vendors (except Joshua's recent statement that he's
happy without such hooks).
> The idea is to design a single set of hooks that can be used to
> implement an entire class of replication. This only makes sense after
> existing solutions come to some agreement. I view that as a first step,
> assuming that it is necessary to alter the core in order to implement
> the class of replication in question.
As there's not even *one* existing and open replication solution which
needs patching the backend, you are basing your statements on a false
premise. Thus, speaking of hooks as a "first step" is very confusing, at
least.
> Once that step is complete, ideally you'd be able to implement Postgres-
> R without having to patch the postgresql backend to accomplish it
> (except for maybe adding the syntax for your solution). Then, when a
> syntax is agreed upon, you won't need to patch the backend at all. Isn't
> that the goal, to be able to implement your replication without patching
> the backend?
No, it's not. What would that buy me? My goal is to write a widely
usable replication system. How that interacts with the backend is of
much less importance to me. And currently fiddling with the backend is
much easier than maintaining hooks and keep all the replication stuff
separate.
Postgres-R can be one of the solutions used to decide what hooks we
need. Waiting for hooks to establish before implementing Postgres-R
would be what you call 'putting the cart before the horse'.
Regards
Markus
