Subject: Some minor error fixes

From: Alexander Law <[email-masked]>
Date: Mon, 18 Apr 2016 08:30:00 +0300

Hello,

Please consider fixing some more minor errors.
Patches attached.

Best regards,
Alexander

-----
Alexander Lakhin
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

diff --git a/doc/src/sgml/ecpg.sgml b/doc/src/sgml/ecpg.sgml
index 8748b9f..fdd9707 100644
--- a/doc/src/sgml/ecpg.sgml
+++ b/doc/src/sgml/ecpg.sgml
@@ -3917,7 +3917,7 @@ typedef struct sqlda_struct sqlda_t;
       <term><literal>sqln</></term>
       <listitem>
        <para>
-        It contains the number of input parameters for a parametrized query
+        It contains the number of input parameters for a parametrized query in
         case it's passed into <command>OPEN</command>, <command>DECLARE</command> or
         <command>EXECUTE</command> statements using the <literal>USING</literal>
         keyword. In case it's used as output of <command>SELECT</command>,
diff --git a/doc/src/sgml/ecpg.sgml b/doc/src/sgml/ecpg.sgml
index 8748b9f..af37e5d 100644
--- a/doc/src/sgml/ecpg.sgml
+++ b/doc/src/sgml/ecpg.sgml
@@ -636,7 +636,7 @@ EXEC SQL DEALLOCATE PREPARE <replaceable>name</replaceable>;
 <programlisting>
 EXEC SQL INSERT INTO sometable VALUES (:v1, 'foo', :v2);
 </programlisting>
-    This statements refers to two C variables named
+    This statement refers to two C variables named
     <varname>v1</varname> and <varname>v2</varname> and also uses a
     regular SQL string literal, to illustrate that you are not
     restricted to use one kind of data or the other.
diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml
index 522128e..9c96d8f 100644
--- a/doc/src/sgml/protocol.sgml
+++ b/doc/src/sgml/protocol.sgml
@@ -2850,7 +2850,7 @@ CancelRequest (F)
 <para>
                 The cancel request code.  The value is chosen to contain
                 <literal>1234</> in the most significant 16 bits, and <literal>5678</> in the
-                least 16 significant bits.  (To avoid confusion, this code
+                least significant 16 bits.  (To avoid confusion, this code
                 must not be the same as any protocol version number.)
 </para>
 </listitem>
@@ -4656,7 +4656,7 @@ SSLRequest (F)
 <para>
                 The <acronym>SSL</acronym> request code.  The value is chosen to contain
                 <literal>1234</> in the most significant 16 bits, and <literal>5679</> in the
-                least 16 significant bits.  (To avoid confusion, this code
+                least significant 16 bits.  (To avoid confusion, this code
                 must not be the same as any protocol version number.)
 </para>
 </listitem>

-- 
Sent via pgsql-docs mailing list ([email-masked])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

---

From: Peter Eisentraut <[email-masked]>
Date: Tue, 3 May 2016 21:10:48 -0400

> Please consider fixing some more minor errors.

fixed

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

---

From: Alexander Law <[email-masked]>
Date: Wed, 4 May 2016 17:40:45 +0300

Hello Peter,

Thanks!
Please have a look at the some more errors.
Regarding second patch, I think, that inconsistency should be fixed by 
omitting '_name', as this parameter could also include a password.

Best regards,
Alexander

diff --git a/doc/src/sgml/ecpg.sgml b/doc/src/sgml/ecpg.sgml
index 1e285d9..8c0934a 100644
--- a/doc/src/sgml/ecpg.sgml
+++ b/doc/src/sgml/ecpg.sgml
@@ -6190,7 +6190,7 @@ cc -c test_mod.c -o test_mod.o
 
    <para>
     Next, generate <filename>test_cpp.o</> by compiling
-    <filename>test_cpp.cpp</> with the C++ compiler:.
+    <filename>test_cpp.cpp</> with the C++ compiler:
 <programlisting>
 c++ -c test_cpp.cpp -o test_cpp.o
 </programlisting>
@@ -7830,7 +7830,7 @@ main(void)
    this mode is active, it tries to behave as if it were the <productname>Informix</productname>
    precompiler for <productname>Informix</productname> E/SQL. Generally spoken this will allow you to use
    the dollar sign instead of the <literal>EXEC SQL</> primitive to introduce
-   embedded SQL commands.:
+   embedded SQL commands:
 <programlisting>
 $int j = 3;
 $CONNECT TO :dbname;
@@ -7902,7 +7902,7 @@ EXEC SQL FETCH MYCUR INTO :userid;
       <listitem>
        <para>
         This statement closes the current connection. In fact, this is a
-        synonym for ECPG's <literal>DISCONNECT CURRENT</>.:
+        synonym for ECPG's <literal>DISCONNECT CURRENT</>:
 <programlisting>
 $CLOSE DATABASE;                /* close the current connection */
 EXEC SQL CLOSE DATABASE;
diff --git a/doc/src/sgml/ecpg.sgml b/doc/src/sgml/ecpg.sgml
index 8c0934a..35f7f11 100644
--- a/doc/src/sgml/ecpg.sgml
+++ b/doc/src/sgml/ecpg.sgml
@@ -6296,9 +6296,9 @@ EXEC SQL ALLOCATE DESCRIPTOR mydesc;
 
    <refsynopsisdiv>
 <synopsis>
-CONNECT TO <replaceable>connection_target</replaceable> [ AS <replaceable>connection_name</replaceable> ] [ USER <replaceable>connection_user_name</replaceable> ]
+CONNECT TO <replaceable>connection_target</replaceable> [ AS <replaceable>connection_name</replaceable> ] [ USER <replaceable>connection_user</replaceable> ]
 CONNECT TO DEFAULT
-CONNECT <replaceable>connection_user_name</replaceable>
+CONNECT <replaceable>connection_user</replaceable>
 DATABASE <replaceable>connection_target</replaceable>
 </synopsis>
    </refsynopsisdiv>
diff --git a/doc/src/sgml/ref/pg_xlogdump.sgml b/doc/src/sgml/ref/pg_xlogdump.sgml
index 54ef0a7..445da93 100644
--- a/doc/src/sgml/ref/pg_xlogdump.sgml
+++ b/doc/src/sgml/ref/pg_xlogdump.sgml
@@ -149,7 +149,7 @@ PostgreSQL documentation
 
      <varlistentry>
       <term><option>-t <replaceable>timeline</replaceable></option></term>
-      <term><option>--timelime=<replaceable>timeline</replaceable></option></term>
+      <term><option>--timeline=<replaceable>timeline</replaceable></option></term>
       <listitem>
        <para>
         Timeline from which to read log records. The default is to use the

---

From: Peter Eisentraut <[email-masked]>
Date: Wed, 4 May 2016 14:11:59 -0400

fixed

---

From: Alexander Law <[email-masked]>
Date: Wed, 4 May 2016 22:04:59 +0300

Thank you!
I have some more errors written down, maybe they are worth fixing too.

Second patch is for consistency in [1].
(I think XMLValidate could be aligned with "IS VALID predicate")
Third patch is for language name teared down in [1].
It seems that root of this typo is as far as in SQL Standard (see M015 
description in [2]), but IMO it should be fixed anyway.

[1] 
http://www.postgresql.org/docs/9.5/static/unsupported-features-sql-standard.html
[2] 
http://jtc1sc32.org/doc/N1501-1550/32N1529T-text%20for%20FCD%209075-9.pdf

>> omitting '_name', as this parameter could also include a password.

diff --git a/doc/src/sgml/gin.sgml b/doc/src/sgml/gin.sgml
index a392f94..b805af5 100644
--- a/doc/src/sgml/gin.sgml
+++ b/doc/src/sgml/gin.sgml
@@ -539,7 +539,7 @@
        <function>extractQuery</> to pass additional data to the
        <function>consistent</> and <function>comparePartial</> methods.
        To use it, <function>extractQuery</> must allocate
-       an array of <literal>*nkeys</> Pointers and store its address at
+       an array of <literal>*nkeys</> pointers and store its address at
        <literal>*extra_data</>, then store whatever it wants to into the
        individual pointers.  The variable is initialized to <symbol>NULL</symbol> before
        call, so this argument can simply be ignored by operator classes that
diff --git a/src/backend/catalog/sql_features.txt b/src/backend/catalog/sql_features.txt
index fd9e78d..71c08af 100644
--- a/src/backend/catalog/sql_features.txt
+++ b/src/backend/catalog/sql_features.txt
@@ -656,10 +656,10 @@ X271	XMLValidate: data-driven case			NO
 X272	XMLValidate: ACCORDING TO clause			NO	
 X273	XMLValidate: ELEMENT clause			NO	
 X274	XMLValidate: schema location			NO	
-X281	XMLValidate: with DOCUMENT option			NO	
+X281	XMLValidate with DOCUMENT option			NO	
 X282	XMLValidate with CONTENT option			NO	
 X283	XMLValidate with SEQUENCE option			NO	
-X284	XMLValidate NAMESPACE without ELEMENT clause			NO	
+X284	XMLValidate: NAMESPACE without ELEMENT clause			NO	
 X286	XMLValidate: NO NAMESPACE with ELEMENT clause			NO	
 X300	XMLTable			NO	
 X301	XMLTable: derived column list option			NO	
diff --git a/src/backend/catalog/sql_features.txt b/src/backend/catalog/sql_features.txt
index 71c08af..569a43f 100644
--- a/src/backend/catalog/sql_features.txt
+++ b/src/backend/catalog/sql_features.txt
@@ -520,7 +520,7 @@ M011	Datalinks via Ada			NO
 M012	Datalinks via C			NO	
 M013	Datalinks via COBOL			NO	
 M014	Datalinks via Fortran			NO	
-M015	Datalinks via M			NO	
+M015	Datalinks via MUMPS			NO	
 M016	Datalinks via Pascal			NO	
 M017	Datalinks via PL/I			NO	
 M018	Foreign data wrapper interface routines in Ada			NO

---

From: Peter Eisentraut <[email-masked]>
Date: Fri, 13 May 2016 21:41:26 -0400

> description in [2]), but IMO it should be fixed anyway.

I have fixed #1 and #2 but left #3 as it is in the SQL standard.  (I 
think M and MUMPS are the same thing.)

---

From: Alexander Law <[email-masked]>
Date: Sat, 14 May 2016 09:23:02 +0300

Hello Peter,

Thank you!
I see that M is just an alias for MUMPS. I stumbled upon the 
inconsistency between B015, B115, B125, M022 on the one side and M015 on 
the other. Anyway, it's definitely not a bug in our docs.

Please look at the following errors/fixes.

Patch #2 is for consistency on [1].
Bug #6 is the most interesting. Table "Table F-17. Hash Algorithm 
Speeds" on [2] contains following row:
/Algorithm | Hashes/sec//
//crypt-bf/5 | 13504/
And there is a following note below the table:
/For reference: john -test shows 213 loops/sec for crypt-bf/5. (The very 
small difference in results is in accordance with the fact that the 
crypt-bf implementation in pgcrypto is the same one used in John the 
Ripper.)/
It seems that the number 213 is out of sync with the table contents. 
("Very small difference" was indeed present before [3]. See [4].)
As I can't reproduce exact numbers on my machine, I suggest to slightly 
increase the number that was specified in the table (+2 as before).

[1] http://www.postgresql.org/docs/current/static/reference-server.html
[2] 
http://www.postgresql.org/docs/current/static/pgcrypto.html#PGCRYPTO-HASH-SPEED-TABLE
[3] 
https://github.com/postgres/postgres/commit/d6464fdc0a591662e5e5ee1b0303932e89cb027c
[4] 
http://www.postgresql.org/docs/9.1/static/pgcrypto.html#PGCRYPTO-HASH-SPEED-TABLE

Best regards,
Alexander

---

From: Alexander Law <[email-masked]>
Date: Sat, 14 May 2016 09:23:49 +0300

Hello Peter,

Thank you!

Best regards,
Alexander

> think M and MUMPS are the same thing.)

diff --git a/doc/src/sgml/ref/pgtesttiming.sgml b/doc/src/sgml/ref/pgtesttiming.sgml
index d5e231f..8490f83 100644
--- a/doc/src/sgml/ref/pgtesttiming.sgml
+++ b/doc/src/sgml/ref/pgtesttiming.sgml
@@ -170,7 +170,7 @@ Histogram of timing durations:
 
   <para>
    In this configuration, the sample <command>EXPLAIN ANALYZE</command> above
-   takes 115.9 ms.  That's 1061 nsec of timing overhead, again a small multiple
+   takes 115.9 ms.  That's 106.1 nsec of timing overhead, again a small multiple
    of what's measured directly by this utility.  That much timing overhead
    means the actual query itself is only taking a tiny fraction of the
    accounted for time, most of it is being consumed in overhead instead.  In
diff --git a/doc/src/sgml/ref/pg_xlogdump.sgml b/doc/src/sgml/ref/pg_xlogdump.sgml
index 445da93..296f1ac 100644
--- a/doc/src/sgml/ref/pg_xlogdump.sgml
+++ b/doc/src/sgml/ref/pg_xlogdump.sgml
@@ -16,7 +16,7 @@ PostgreSQL documentation
 
  <refnamediv>
   <refname>pg_xlogdump</refname>
-  <refpurpose>Display a human-readable rendering of the write-ahead log of a <productname>PostgreSQL</productname> database cluster</refpurpose>
+  <refpurpose>display a human-readable rendering of the write-ahead log of a <productname>PostgreSQL</productname> database cluster</refpurpose>
  </refnamediv>
 
  <refsynopsisdiv>
diff --git a/doc/src/sgml/sepgsql.sgml b/doc/src/sgml/sepgsql.sgml
index a012094..6f80933 100644
--- a/doc/src/sgml/sepgsql.sgml
+++ b/doc/src/sgml/sepgsql.sgml
@@ -675,13 +675,13 @@ ERROR:  SELinux: security policy violation
      </row>
      <row>
       <entry><literal>sepgsql_mcstrans_in(text) returns text</literal></entry>
-      <entry>Translates the given qualifies MLS/MCS range into raw format if
+      <entry>Translates the given qualified MLS/MCS range into raw format if
       the mcstrans daemon is running.
       </entry>
      </row>
      <row>
       <entry><literal>sepgsql_mcstrans_out(text) returns text</literal></entry>
-      <entry>Translates the given raw MCS/MCS range into qualified format if
+      <entry>Translates the given raw MLS/MCS range into qualified format if
       the mcstrans daemon is running.
       </entry>
      </row>
diff --git a/doc/src/sgml/install-windows.sgml b/doc/src/sgml/install-windows.sgml
index 4e92cc9..8cd189c 100644
--- a/doc/src/sgml/install-windows.sgml
+++ b/doc/src/sgml/install-windows.sgml
@@ -84,7 +84,7 @@
 
  <para>
   Both 32-bit and 64-bit builds are possible with the Microsoft Compiler suite.
-  32-bit PostgreSQL buils are possible with
+  32-bit PostgreSQL builds are possible with
   <productname>Visual Studio 2005</productname> to
   <productname>Visual Studio 2015</productname> (including Express editions),
   as well as standalone Windows SDK releases 6.0 to 7.1.
diff --git a/doc/src/sgml/btree-gist.sgml b/doc/src/sgml/btree-gist.sgml
index f4afc09..e8a5622 100644
--- a/doc/src/sgml/btree-gist.sgml
+++ b/doc/src/sgml/btree-gist.sgml
@@ -98,7 +98,7 @@ INSERT 0 1
   <title>Authors</title>
 
   <para>
-   Teodor Sigaev (<email>[email-masked]</email>) ,
+   Teodor Sigaev (<email>[email-masked]</email>),
    Oleg Bartunov (<email>[email-masked]</email>), and
    Janko Richter (<email>[email-masked]</email>).  See
    <ulink url="http://www.sai.msu.su/~megera/postgres/gist/"></ulink>
diff --git a/doc/src/sgml/pgcrypto.sgml b/doc/src/sgml/pgcrypto.sgml
index a3b987a..010c174 100644
--- a/doc/src/sgml/pgcrypto.sgml
+++ b/doc/src/sgml/pgcrypto.sgml
@@ -407,7 +407,7 @@ gen_salt(type text [, iter_count integer ]) returns text
       <literal>crypt-bf</literal> numbers are taken using a simple program that
       loops over 1000 8-character passwords.  That way I can show the speed
       with different numbers of iterations.  For reference: <literal>john
-      -test</literal> shows 213 loops/sec for <literal>crypt-bf/5</>.
+      -test</literal> shows 13506 loops/sec for <literal>crypt-bf/5</>.
       (The very small
       difference in results is in accordance with the fact that the
       <literal>crypt-bf</literal> implementation in <filename>pgcrypto</>

---

From: Peter Eisentraut <[email-masked]>
Date: Thu, 14 Jul 2016 22:36:19 -0400

> Please look at the following errors/fixes.

I've applied 2, 3, 4, 5.

1 was correct according to my math. (115.9-9.8)/100000*1000*1000 = 1061

6 looked too complicated to me. ;-)  Can you explain where you got your
number from?

---

From: Alexander Law <[email-masked]>
Date: Fri, 15 Jul 2016 07:06:22 +0300

Thank you, Peter.

Regarding 1, you're right, I didn't see "per row" in that sentence and 
decided that it was total overhead (and then again I should change nsec 
to msec).

Regarding 6, please look at the old documentation:
http://www.postgresql.org/docs/9.1/static/pgcrypto.html#PGCRYPTO-HASH-SPEED-TABLE
It contains "crypt-bf/5 | 211" in the table and "john -test shows 213 
loops/sec for crypt-bf/5" below the table. (The difference is 2 loops 
per second).

Current documentation:
https://www.postgresql.org/docs/current/static/pgcrypto.html#PGCRYPTO-HASH-SPEED-TABLE
contains:
"crypt-bf/5     13504" in the table (number is increased with the faster 
CPU) and still "john -test shows 213 loops/sec for crypt-bf/5" below the 
table.
So I propose to change 213 below the table to 13504 + 2 (previous 
difference).
Or maybe we should rerun all the benchmarks and update all the numbers 
(see commit d6464fdc).

Best wishes,
Alexander

---

From: Peter Eisentraut <[email-masked]>
Date: Mon, 8 Aug 2016 09:29:01 -0400

> So I propose to change 213 below the table to 13504 + 2 (previous 

makes sense, fixed