Hi Aaron,

It would be pretty easy to check the truncate behavior by running another slon process, with a test 
cluster and table, and trying it out.  I myself don't know if "truncate" is something Slony explicitly 
supports (and I am guessing not).

I'd think about it this way: the log shipping process is only another "slon" process (with an archive 
flag -a to save out all the commands issued by the slon).  If your existing slon process to your 
regular subscribers won't do what you want (truncate), then your slon -a (log shipping) won't do it 
either.  If it will, then the slon -a should also.  See what I mean?

I assume from your mail that you are going to have your subscribers issue a "truncate" on their end, 
and do some sort of external-to-Slony process to re-replicate the table in question?  Treat your 
log-shipping subscriber the same as your regular subscribers.  Just before you truncate and munge your 
data, turn off your slon -a process.  You should note the log number in 
_yourclustername.sl_archive_tracking when you turn off your slon.  Make sure to send that number to 
your remote log subscriber.  He'll need to ingest the last CORRECT pre-munge log (that number you're 
going to send him), and then turn off his log-ingest process after that.  Then he would do the 
truncate on the data table, receive and ingest a new set of munged data from you (via your copy 
out/his copy in or another re-replication process you had in mind).  You then restart your log-ship 
slon -a process, and then he'll restart his log-ingest process.  Just make sure not to make other 
changes to other tables when your slon -a is inactive.

Hope this helps.
-Jennifer

Aaron Brown wrote:
> List,
> 
> I have a large table (16 million rows), that I need to pull out of
> replication, do some munging, and then rereplicate (in a new set) as part of
> a release.  To explain better, the process will be to drop the table (which
> is in set 2) from replication, run a large stored procedure that munges the
> data, then rereplicate the table by adding it to a new set (set 12).  The
> subscribers obviously truncate the table and rereplicate the entire table.
> This process works fine.
> 
> The catch here is that we have a remote log shipped node off of one of the
> subscribers.  I know the schema changes themselves do not propagate.  What
> I¹m unclear on is whether or not the log shipping archive files will contain
> the TRUNCATE and COPY statements to recreate this table, or if I will have
> to do something (like recreate the remote node from scratch) to make that
> happen? 
> 
> Thanks ­ any help you can provide is appreciated.  If you need more
> specifics or configs, please let me know.
> 
> Aaron
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Slony1-general mailing list
> Slony1-general at lists.slony.info
> http://lists.slony.info/mailman/listinfo/slony1-general