<html><body><div style="color:#000; background-color:#fff; font-family:times new roman, new york, times, serif;font-size:12pt"><div><span>Hi Steve</span></div><div><br><span></span></div><div><span>Thanks for your reply.</span></div><div><br><span></span></div><div><span>Kind regards.</span></div><div><br><span></span></div><div><span>David.</span></div><div><br></div> <div style="font-family: times new roman, new york, times, serif; font-size: 12pt;"> <div style="font-family: times new roman, new york, times, serif; font-size: 12pt;"> <div dir="ltr"> <font face="Arial" size="2"> <hr size="1"> <b><span style="font-weight:bold;">De :</span></b> Steve Singer <steve@ssinger.info><br> <b><span style="font-weight: bold;">À :</span></b> David TECHER <davidtecher@yahoo.fr> <br><b><span style="font-weight: bold;">Cc :</span></b> Slony Hackers <slony1-hackers@lists.slony.info> <br> <b><span style="font-weight: bold;">Envoyé le
:</span></b> Lundi 27 février 2012 4h16<br> <b><span style="font-weight: bold;">Objet :</span></b> Re: [Slony1-hackers] Updating table DDL by removing table/adding from/to replication<br> </font> </div> <br>On Sun, 26 Feb 2012, David TECHER wrote:<br><br>> Hi<br>> <br>> I use Slony 1.2.22<br>> <br>> Replication: 1 master and 3 slaves.<br><br>> "Slony command DDL" can not be used because it will take to much time and<br>> we've got a lot of replicated tables.<br>> I am afraid that window of week-end will be not enough.<br><br>I assume the problem is that you have a lot of tables and that the time slony takes to remove the replication triggers on each table in execute_script is to long. You should plan an upgrade to 2.x since execute script no longer does this.<br><br>> For the next update, what I would like to suggest to my team ( and we will<br>> have the intention to test if I can convice them) is<br>>
<br>> 1) removing all tables - to be altered - from replication using set drop<br>> table(origin=??,id=??)<br>> <br>> 2) apply all DDL queries to the future altered table ( usual way : psql<br>> ....database)<br>> <br>> 3) back all altered tables to replication :<br>> - create set (...)<br>> - set add table(...) to new set<br>> - merge set (new set to the old set associated to the altered<br>> table).<br>> <br>> Can we do that? <br><br>I don't see any reason why that wouldn't work. You would need to subscribe the subscribers to the new set before you do the merge set. This will cause the tables on the subscriber to be truncated and re-populated. As always, you should make sure you do proper 'wait for events' so the subscribe doesn't happen
before all of the subscriber has seen the drop table.<br><br>Steve<br><br><br>> <br>> There is no concurrent activity and we've got the window of the week-end.<br>> <br>> Thanks for your reply.<br>> <br>> <br><br><br> </div> </div> </div></body></html>