At 16:53 21/11/2007, Robert Landrum wrote:
>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.

Well, that's basically what slony does, but without rejecting 
connections on the master nor slave. The initial replication is quite 
equivalent to a big pg_dump master | pgsql slave (a bunch of COPY TO 
STDOUT's piped into COPY FROM STDIN's), just "synchronized" with the 
start of the update collection (precisely so you can do it on a live 
database...).

Note that you're not using the latest version of slony, so you might 
have hit some instances where the replication is not as fast as it 
could be because there was an issue in index creation deferral with 
postgresql 8.2 which was fixed in 1.2.11. With the fix in, there's no 
reason for it to be any longer than a dump + a restore (actually a 
bit faster than that since the two operations are done in parallel, 
so more like max(dump,restore)).

Jacques.