[prev in list] [next in list] [prev in thread] [next in thread] 

List:       slony1-general
Subject:    [Slony1-general] fix some typos in docs
From:       Euler Taveira de Oliveira <euler () timbira ! com>
Date:       2006-04-10 23:40:15
Message-ID: 443AECDF.7090502 () timbira ! com
[Download RAW message or body]

Hi,

Attached is a patch that fix some misspellings.

Best Wishes,

-- 
Euler Taveira de Oliveira


["typos.diff" (text/plain)]

*** ./doc/concept/Slony-I-concept.nr.orig	2006-04-10 19:24:24.000000000 -0300
--- ./doc/concept/Slony-I-concept.nr	2006-04-10 20:34:33.000000000 -0300
***************
*** 197,203 ****
  replicate schema changes is not possible without substantial work
  in the core PostgreSQL system.
  .PP
! Moreover, very often database schema chages 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
--- 197,203 ----
  replicate schema changes is not possible without substantial work
  in the core PostgreSQL system.
  .PP
! 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,289 ****
  .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\
  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\
--- 283,289 ----
  .pso pic figure-1.pic
  .PP
  Figure 1 illustrates a replication configuration that has 2 data
! 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,603 ****
  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.
  .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
--- 597,603 ----
  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
! 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,623 ****
  and
  .XREF subscribing SN
  .PP
! Configuration chage 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.
--- 617,623 ----
  and
  .XREF subscribing SN
  .PP
! 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,794 ****
  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.
  .IP 3.
  For each table it will use the PostgreSQL command COPY on both
  sides and forward the data stream.
--- 788,794 ----
  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 dependencies.
  .IP 3.
  For each table it will use the PostgreSQL command COPY on both
  sides and forward the data stream.
*** ./doc/implementation/Slony-I-implementation.nr.orig	2006-04-10 20:33:37.000000000 -0300
--- ./doc/implementation/Slony-I-implementation.nr	2006-04-10 20:34:12.000000000 -0300
***************
*** 120,126 ****
  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.
  .\" ****
  .NH 2
  Table sl_listen
--- 120,126 ----
  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.
  .\" ****
  .NH 2
  Table sl_listen


[prev in list] [next in list] [prev in thread] [next in thread]