diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml
index 73c6c03..af4f922 100644
--- a/doc/src/sgml/libpq.sgml
+++ b/doc/src/sgml/libpq.sgml
@@ -4653,7 +4653,7 @@ int PQflush(PGconn *conn);
     </programlisting>
     could be much more efficiently done with:
     <programlisting>
-     UPDATE mytable SET x = x + 1;
+     UPDATE mytable SET x = x + 1 WHERE id = 42;
     </programlisting>
    </para>
 
@@ -4696,7 +4696,7 @@ int PQflush(PGconn *conn);
      <link linkend="libpq-pqsetnonblocking">non-blocking mode</link>. If used in
      blocking mode it is possible for a client/server deadlock to occur. The
      client will block trying to send queries to the server, but the server will
-     block trying to send results from queries it's already processed to the
+     block trying to send results from queries it has already processed to the
      client. This only occurs when the client sends enough queries to fill its
      output buffer and the server's receive buffer before switching to
      processing input from the server, but it's hard to predict exactly when
@@ -5015,7 +5015,7 @@ int PQgetNextQuery(PGconn *conn);
      <listitem>
       <para>
       Returns the number of queries still in the queue for this batch, not
-      including any query that's currently having results being processsed.
+      including any query that's currently having results being processed.
       This is the number of times <function>PQgetNextQuery</function> has to be
       called before the query queue is empty again.
 
@@ -5037,7 +5037,7 @@ int PQqueriesInBatch(PGconn *conn);
 
      <listitem>
       <para>
-       Returns 1 if the batch curently being received on a
+       Returns 1 if the batch currently being received on a
        <application>libpq</application> connection in <link
        linkend="libpq-batch-mode">batch mode</link> is
        <link linkend="libpq-batch-errors">aborted</link>, 0