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
signature.asc
Description: This is a digitally signed message part.
