Browse files

Documentation updates for bug 217


  • Loading branch information...
1 parent ad0b962 commit e32787bba18fd66330dfe4ea3d88ca3d193a2630 @ssinger ssinger committed Jun 13, 2011
Showing with 52 additions and 0 deletions.
  1. +52 −0 doc/adminguide/ddlchanges.sgml
@@ -13,6 +13,17 @@ for this to be handled rather carefully, otherwise different nodes may
get rather deranged because they disagree on how particular tables are
+<title>DDL Changes with Execute Script</title>
+The <xref linkend="stmtddlscript"> (slonik) command allows you to submit
+a SQL script (that can, but is not required to) contain DDL commands.
+This script will be executed on the event node and then (optionally) replicated
+to every other node in the cluster. You should keep the following in mind
+when using <xref linkend="stmtddlscript">
<para>If you pass the changes through &slony1; via <xref
linkend="stmtddlscript"> (slonik),
this allows you to be certain that the changes take effect at the same
@@ -21,6 +32,7 @@ important to you depending on the nature of your change. You should still
make sure that no transactions are changing the tables that your script
uses while the EXECUTE SCRIPT command is running on the master.</para>
<para>It is essential to use <command>EXECUTE SCRIPT</command> if you
alter the names of tables or the namespace they reside in. If you do not
then &slony1; will be unaware of the new table name.
@@ -60,7 +72,47 @@ DDL change succeeds the next time slon attempts it.</para></listitem>
+<title>Applying DDL Changes Directly</title>
+<para>DDL changes can be applied directly on a node through an
+application such as psql. The DDL changes will not be replicated by &slony1;
+and therefore must be manually applied to every relevant node.
+The following points should be kept in mind when applying DDL changes
+<listitem><para>While DDL changes are not replicated any
+INSERT,UPDATE,DELETE statements that you execute will be replicated.
+This means that you should put DDL changes inside of the same script
+as DML commands because the script will then not behave properly when
+you execute it on other nodes</para></listitem>
+<listitem><para>You are responsible for ensuring that your scripts get
+applied on all other nodes at the correct point during the replication
+stream. The best way of doing this with respect to adding and deleting
+columns is to make sure that new columns always get added on the
+replica nodes first and that columns being removed get dropped from the
+master before they are dropped from the replicas.</para></listitem>
+<listitem><para>DDL changes that rename a replicated table do not
+inform &slony1; of the new table name. If you change then name of
+a replicated table you must allow &slony1; to find the new table name
+by calling <xref linkend="function.updaterelname-integer-integer">
+<para>DDL changes that alter either a primary key, a unique constraint that
+slony is using, or DDL changes that drop columns that come before the
+key or unique constraint that &slony1; is using will require &slony1; too reconfigure the arguments
+on the logtrigger. The function <xref linkend=""> will reconfigure the trigger arguments of any &slony1; log triggers
+that are out of date. If true is passed to this function it will only adjust
+tables that are already locked by the current transaction (if you perform your
+alter table in a transaction and then call repair_log_triggers as part of the same
+transaction then the altered tables will be locked).
+If you pass false to this function then the function will obtain
+an exclusive lock on any table that needs to be reconfigured.
<!-- Keep this comment at the end of the file

0 comments on commit e32787b

Please sign in to comment.