diff --git a/doc/src/sgml/ecpg.sgml b/doc/src/sgml/ecpg.sgml
index e94bb98079014afd2b9b5480b709f479126a801f..7c8b02802d8037e62e5706e9486172a4e2d65a49 100644
--- a/doc/src/sgml/ecpg.sgml
+++ b/doc/src/sgml/ecpg.sgml
@@ -1,4 +1,4 @@
-<!-- $PostgreSQL: pgsql/doc/src/sgml/ecpg.sgml,v 1.99 2010/05/09 16:30:31 tgl Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/ecpg.sgml,v 1.100 2010/05/13 14:16:41 mha Exp $ -->
 
 <chapter id="ecpg">
  <title><application>ECPG</application> - Embedded <acronym>SQL</acronym> in C</title>
@@ -2865,7 +2865,7 @@ struct sqlname
 </programlisting>
   </para>
   <para>
-   There are two compatiblity modes: INFORMIX, INFORMIX_SE
+   There are two compatibility modes: INFORMIX, INFORMIX_SE
   </para>
   <para>
    When linking programs that use this compatibility mode, remember to link
diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml
index 744ddcbd3a2a7c324a693a90b036773cda6a2794..1e7419de4fbc261603f89355db441362620070e8 100644
--- a/doc/src/sgml/high-availability.sgml
+++ b/doc/src/sgml/high-availability.sgml
@@ -1,4 +1,4 @@
-<!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.67 2010/05/03 09:15:17 heikki Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.68 2010/05/13 14:16:41 mha Exp $ -->
 
 <chapter id="high-availability">
  <title>High Availability, Load Balancing, and Replication</title>
@@ -201,7 +201,7 @@ protocol to make nodes agree on a serializable transactional order.
      must query such values from a single server and then use those
      values in write queries.  Another option is to use this replication
      option with a traditional master-slave setup, i.e. data modification
-     queries are sent only to the master and are propogated to the
+     queries are sent only to the master and are propagated to the
      slaves via master-slave replication, not by the replication
      middleware.  Care must also be taken that all
      transactions either commit or abort on all servers, perhaps
@@ -1559,7 +1559,7 @@ if (!triggered)
     node itself.  And you are still getting the benefit of off-loading the
     execution onto the standby. <varname>max_standby_delay</> should
     not be used in this case because delayed WAL files might already
-    contain entries that invalidate the current shapshot.
+    contain entries that invalidate the current snapshot.
    </para>
 
    <para>
@@ -1823,7 +1823,7 @@ LOG:  database system is ready to accept read only connections
    </para>
 
    <para>
-    The statististics collector is active during recovery. All scans, reads, blocks,
+    The statistics collector is active during recovery. All scans, reads, blocks,
     index usage, etc., will be recorded normally on the standby. Replayed
     actions will not duplicate their effects on primary, so replaying an
     insert will not increment the Inserts column of pg_stat_user_tables.
diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml
index c880691438fda6be7fb3ded7df17ae1b4554cbc4..7dc2983a89cf821ec2a8d1ba79047dfa014dbc43 100644
--- a/doc/src/sgml/libpq.sgml
+++ b/doc/src/sgml/libpq.sgml
@@ -1,4 +1,4 @@
-<!-- $PostgreSQL: pgsql/doc/src/sgml/libpq.sgml,v 1.304 2010/04/03 07:22:54 petere Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/libpq.sgml,v 1.305 2010/05/13 14:16:41 mha Exp $ -->
 
 <chapter id="libpq">
  <title><application>libpq</application> - C Library</title>
@@ -6635,7 +6635,7 @@ user=admin
    The default value for <literal>sslmode</> is <literal>prefer</>. As is shown
    in the table, this makes no sense from a security point of view, and it only
    promises performance overhead if possible. It is only provided as the default
-   for backwards compatiblity, and not recommended in secure deployments.
+   for backwards compatibility, and not recommended in secure deployments.
   </para>
 
  </sect2>