Mon Feb 7 21:49:55 PST 2005
- Previous message: [Slony1-commit] By cbbrowne: Reshaped sections a bit to improve flow of web pages
- Next message: [Slony1-commit] By cbbrowne: Updated tagging on all of the documents to resolve SGML
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: [Slony1-commit] By cbbrowne: Reshaped sections a bit to improve flow of web pages
- Next message: [Slony1-commit] By cbbrowne: Updated tagging on all of the documents to resolve SGML
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Slony1-commit mailing list