On Mar 3, 2010, at 8:55 AM, Christopher Browne wrote:
> None of this is inherently necessarily terrible.  The one thing I'd
> point out is that it'll be mighty difficult to validate that data is
> correct on D, as it captures changes both from upstream (A) as well as
> potentially having local changes introduced on C.
Thanks for the reply.  Yep, I'm using C and D as a cloned replication cluster in a separate geographic location from where A and B reside.  The thought is that using log shipping reduces network traffic because 1) there are no SYNC events to process and 2) there doesn't need to be a "mesh " of connections among all nodes--I'm restricting the connections by locale.  This way, if something happens in the location of my first cluster (i.e., earthquake or power outage), I can readily point my applications to the second cluster, and proceed operations as normal.

> "We don't make extra changes on C" is a good answer to that :-).

Yep, we keep C tied up so that no additional data changes can be made to it until the tipover happens ;)

I had figured the intent behind slony logshipping was not to create a separate subscriber, but to provide remote access to the data being replicated.  Technically, the logshipping destination would still be a subscriber, but not in the slony-I sense.  Rather, the logshipping destination would simply be a data store--not much different than using pg_dump to dump to disk doesn't make the disk a "subscriber" to the database.  In fact, the logshipping destination does not have the usual logtrigger() and denyaccess() triggers, thereby making the command to "set session_replication_role to replica" moot, as well as enabling the logshipping destination to in fact serve as a "master" to subsequent subscribers.

Could you elaborate on the original intent of slony logshipping, as discussed and formulated by the development team?

--Richard