Robert Landrum <rlandrum at aol.net> writes:
> Jacques Caron wrote:
>>> this just a limitation of slony? Or is there a workaround I've missed?
>> What other option would you imagine there could be?
>>
>
> Reject Master db connections.  Dump Master.  Load Master data onto
> Slave.  Start Master/Slave replication.  Re-allow Master DB
> connections.
>
> I would imaging that there'd need to be some sort of seeding operation
> in between the data load and the starting of the master and slave
> replication, where one populates the slony tables with the sync status
> of each of the tables/sequences in the set.
>
> Obviously that's not something that is supported, but that was kinda
> what I had in mind when I started.

That is decidedly NOT how things work...

In order for Slony-I to be certain that data has been faithfully
copied over, the "seeding operation" is that the subscription process
copies all of the data over.

As a result, if you loaded *any* data into the subscriber, that data
will be thrown away.  There is therefore no point in loading anything
onto the subscriber aside from the schema.  Pre-loading data is a
waste of time.
-- 
(format nil "~S@~S" "cbbrowne" "linuxdatabases.info")
http://linuxdatabases.info/info/wp.html
"What we need is either less corruption, or more chance to participate
in it."  -- Unknown