CVS User Account cvsuser
Mon Feb 7 21:49:55 PST 2005
Log Message:
-----------
Added document on handling of plain paths...

Fixed tagging errors and such in various files

Modified Files:
--------------
    slony1-engine/doc/adminguide:
        dropthings.sgml (r1.8 -> r1.9)
        slon.sgml (r1.7 -> r1.8)
        slonik.sgml (r1.8 -> r1.9)

Added Files:
-----------
    slony1-engine/doc/adminguide:
        plainpaths.sgml (r1.1)

-------------- next part --------------
Index: slon.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/slon.sgml,v
retrieving revision 1.7
retrieving revision 1.8
diff -Ldoc/adminguide/slon.sgml -Ldoc/adminguide/slon.sgml -u -w -r1.7 -r1.8
--- doc/adminguide/slon.sgml
+++ doc/adminguide/slon.sgml
@@ -111,7 +111,7 @@
       Since they are not actually generating any data to replicate to
       other nodes, such SYNC events are of little value.  You might
       want to increase this parameter to something quite a bit higher
-      than the <option>-s</option SYNC check interval, so that
+      than the <option>-s</option> SYNC check interval, so that
       subscriber nodes won't generate and propagate as many SYNC
       events.  The once per minute that is the default seems amply
       often.
Index: slonik.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/slonik.sgml,v
retrieving revision 1.8
retrieving revision 1.9
diff -Ldoc/adminguide/slonik.sgml -Ldoc/adminguide/slonik.sgml -u -w -r1.8 -r1.9
--- doc/adminguide/slonik.sgml
+++ doc/adminguide/slonik.sgml
@@ -65,7 +65,7 @@
   these sorts of scripting languages already have perfectly good ways
   of managing variables, doing iteration, and such.</para>
   
-  <para>See also <link linkend="slonikcommands"> Slonik Commands
+  <para>See also <link linkend="slonikref"> Slonik Command Summary
   </link>. </para>
 
  </refsect1>
@@ -80,7 +80,6 @@
  </refsect1>
 </refentry>
 
-
 <!-- Keep this comment at the end of the file
 Local variables:
 mode: sgml
--- /dev/null
+++ doc/adminguide/plainpaths.sgml
@@ -0,0 +1,33 @@
+<!-- $Id: plainpaths.sgml,v 1.1 2005/02/07 21:49:52 cbbrowne Exp $ -->
+<sect1 id="plainpaths"><title><productname>Slony-I</productname> Path Communications</title>
+
+<para>To Do...
+
+<para> Basically need to discuss what STORE PATHs are about, and
+distinguish them from the admin conninfo entries in the slonik
+preamble.
+
+<para> This isn't an issue for people with simple networks; it matters
+for those with complex firewall configurations, nodes at multiple
+locations, and the issue where nodes may not be able to all talk to
+one another at a uniform set of network addresses.
+
+<para> There is also room for discussion of SSH tunnelling here...
+
+</sect1>
+<!-- Keep this comment at the end of the file
+Local variables:
+mode:sgml
+sgml-omittag:nil
+sgml-shorttag:t
+sgml-minimize-attributes:nil
+sgml-always-quote-attributes:t
+sgml-indent-step:1
+sgml-indent-data:t
+sgml-parent-document:nil
+sgml-default-dtd-file:"./reference.ced"
+sgml-exposed-tags:nil
+sgml-local-catalogs:("/usr/lib/sgml/catalog")
+sgml-local-ecat-files:nil
+End:
+-->
Index: dropthings.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/dropthings.sgml,v
retrieving revision 1.8
retrieving revision 1.9
diff -Ldoc/adminguide/dropthings.sgml -Ldoc/adminguide/dropthings.sgml -u -w -r1.8 -r1.9
--- doc/adminguide/dropthings.sgml
+++ doc/adminguide/dropthings.sgml
@@ -11,10 +11,11 @@
 linkend="stmtdropnode">DROP NODE</link></command> should do the
 trick.</para>
 
-<para>This will lead to <productname>Slony-I</productname> dropping the triggers
-(generally that deny the ability to update data), restoring the
-<quote>>native</quote> triggers, dropping the schema used by
-<productname>Slony-I</productname>, and the slon process for that node terminating
+<para>This will lead to <productname>Slony-I</productname> dropping
+the triggers (generally that deny the ability to update data),
+restoring the <quote>native</quote> triggers, dropping the schema used
+by <productname>Slony-I</productname>, and the <link linkend="slon">
+<command>slon</command> </link> process for that node terminating
 itself.</para>
 
 <para>As a result, the database should be available for whatever use


More information about the Slony1-commit mailing list