Log Message:
-----------
Fixes to spellings of things in *roff documents, per Euler Taveira de Oliveira

Modified Files:
--------------
    slony1-engine/doc/concept:
        Slony-I-concept.nr (r1.3 -> r1.4)
    slony1-engine/doc/implementation:
        Slony-I-implementation.nr (r1.5 -> r1.6)

-------------- next part --------------
Index: Slony-I-concept.nr
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/concept/Slony-I-concept.nr,v
retrieving revision 1.3
retrieving revision 1.4
diff -Ldoc/concept/Slony-I-concept.nr -Ldoc/concept/Slony-I-concept.nr -u -w -r1.3 -r1.4
--- doc/concept/Slony-I-concept.nr
+++ doc/concept/Slony-I-concept.nr
@@ -197,7 +197,7 @@
 replicate schema changes is not possible without substantial work
 in the core PostgreSQL system.
 .PP
-Moreover, very often database schema chages are not single,
+Moreover, very often database schema changes are not single,
 isolated DDL statements that can occur at any time within a
 running system.  Instead they tend to be groups of DDL and DML
 statements that modify multiple database objects and do mass data
@@ -283,7 +283,7 @@
 .pso pic figure-1.pic
 .PP
 Figure 1 illustrates a replication configuration that has 2 data
-sets with different origins. To replicate both date sets to Node\
+sets with different origins. To replicate both data sets to Node\
 C it is not required that Node\ C really communicates with the
 origin of Set\ 1. This scenario has full redundancy for every
 node.  Obviously if Node\ C fails, the masters of Set\ 1 and Set\
@@ -597,7 +597,7 @@
 that node C might fail at any time, even before it would be able
 to provide the current data snapshot or even the subscribe
 message itself to D and D would be reconfigured to talk to B as a
-substiture provider.
+substitute provider.
 .PP
 As a side note, the configuration in figure 2 with a set
 originating on node A is the very setup the author used during
@@ -617,7 +617,7 @@
 and
 .XREF subscribing SN
 .PP
-Configuration chage events carry all necessary information to
+Configuration change events carry all necessary information to
 modify the local configuration information in the event data row.
 Processing consists more or less of storing or deleting a row in
 one of the \*[Slony1] control tables.
@@ -788,7 +788,7 @@
 All triggers on the tables in the set get disabled to speed up
 the data copy process and to avoid possible foreign key conflicts
 resulting from copying the data in the wrong order or because of
-circular dependancies.
+circular dependencies.
 .IP 3.
 For each table it will use the PostgreSQL command COPY on both
 sides and forward the data stream.
Index: Slony-I-implementation.nr
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/implementation/Slony-I-implementation.nr,v
retrieving revision 1.5
retrieving revision 1.6
diff -Ldoc/implementation/Slony-I-implementation.nr -Ldoc/implementation/Slony-I-implementation.nr -u -w -r1.5 -r1.6
--- doc/implementation/Slony-I-implementation.nr
+++ doc/implementation/Slony-I-implementation.nr
@@ -120,7 +120,7 @@
 all possible connections so that the configuration is in place
 for an eventual failover. An sl_path entry alone does not
 actually cause a connection to be established. This requires
-sl_listen and or sl_subscribe entries as well.
+sl_listen and/or sl_subscribe entries as well.
 .\" ****
 .NH 2
 Table sl_listen