Re: Postgres-R: primary key patches

Le mardi 22 juillet 2008, Christopher Browne a écrit :
> A most pointed case where that will cause heartburn of the "I refuse
> to use this" sort is if that disruption needs to take place when
> recovering from the failure of a node. That sort of disruption is
> certainly counterproductive to the usual goal of replication enhancing
> system availability.
>
> Maybe I am misreading you; I rather hope so.

This part of Markus's mail makes me think the need may change if Postgres-R is
ever integrated into -core:

Le mardi 22 juillet 2008, Markus Wanner a écrit :
> As Postgres-R comes with system catalog changes, that's not the case.

So currently to use Postgres-R you'd have to start with a patched code base at
each and every node, because it's how Markus wanted to proceed (Postgres-R
being a separated code base). In Postgres-R adding a node to the cluster is
what is done without dump/restore cycle.

Now that he's Open-Sourcing the solution, I hope to see this mode of operation
change, thanks to integration of some key part (catalog changes) of the
project into -core, if possible.

Note that while slony doesn't require a dump/restore to get activated, it
seems to me (as a non user of it) that it still plays with catalog,
preventing "normal" usage of pg_dump...

I'm not sure which disease I prefer: not being able to dump/restore normally
or getting to have to restore on a specific product version, not the -core
one.

Just my 2 cents, hoping I'm understanding correctly the point at hand here,
--
dim