First, thank you for the prompt reply! From your explanation, I derive
that a table can only ever have one origin. Which on the surface seems
to make obvious sense except that I thought there was the idea that a
subscriber could act as an origin for other subscribers.

I also think I have a misunderstanding about what the 'forward' option
in the SUBSCRIBE statement means. From
http://slony.info/documentation/stmtsubscribeset.html:
    FORWARD = boolean
    Flag whether or not the new subscriber should store the log
information during replication to make it possible candidate for the
provider role for future nodes.

So back to your example: Let's say you have tables A, B and C. There
are nodes X, Y and Z with X being the origin. I want as little impact
on X as possible. Node Y needs to be kept up to date as close to real
time as possible. Node Z serves a special purpose and only needs a
subset of the tables, but replicating all the tables would be
acceptable. It is not as important that Z be kept in real-time sync.
The point is to replicate the data to Z with as little impact on X as
possible. This is why I thought I could use Y as the "origin" for Z. I
thought this was effectively using Y as a forwarder of X.

I'll take my lumps now!


On Tue, Jun 24, 2008 at 8:47 PM, Jan Wieck <JanWieck at yahoo.com> wrote:
>
> On 6/24/2008 4:39 PM, Troy Wolf wrote:
>>
>> I have had what I'd consider to be the most common replication setup:
>> 2 database servers, 1 origin, 1 subscriber, 1 replication set. Slony
>> replication has been working well for months. The situation is
>> changing. See Node 3 below.
>>
>> Node 1 - the origin and main application database
>> Node 2 - the subscriber and main application backup database
>> Node 3 - a special database that only needs a subset of the main
>> application tables
>>
>> I configured Node 2 to allow it to forward.
>
> That's a bit difficult at first (until you get the picture). Since every table can only be a member of one set, in order to have "shared" as well as "individual" subscription sets, one has to create more sets.
>
> Let's say you have tables A, B and C. There are nodes X, Y and Z with X being the origin. Now you want A and C replicated to Y and B and C replicated to Z. So A goes into set 1, B into set 2, C into set 3 and then Y subscribes to 1+3 and Z subscribes 2+3.
>
> There is a lot of special logic inside of slon that ensures that tables in different sets, that origin on the same node, are sync'd together. So this setup will not break integrity on the subscribers.
>
>
> Jan
>
>>
>> My thought was that I'd create a second replication set containing
>> only the subset of tables needed for Node 3 and use Node 2 as the
>> origin.
>>
>> When I try to create the set, I get a PGRES_FATAL_ERROR:  duplicate
>> key violates unique constraint "sl_table_tab_reloid_key"
>>
>> So it appears I can't have a single table in more than one replication
>> set? How do I accomplish what I want?
>> _______________________________________________
>> Slony1-general mailing list
>> Slony1-general at lists.slony.info
>> http://lists.slony.info/mailman/listinfo/slony1-general
>
>
> --
> Anyone who trades liberty for security deserves neither
> liberty nor security. -- Benjamin Franklin
>