From: Alexander Law <exclusion@gmail.com>
Subject: Re: Some minor error fixes
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>,
 "pgsql-docs@postgresql.org" <pgsql-docs@postgresql.org>
References: <571470D8.50907@gmail.com>
 <88f42cdc-48fe-aeb9-60e7-e27587621a55@2ndquadrant.com>
 <572A09ED.8050204@gmail.com>
 <e6d74d55-3c62-4782-9055-5767564a5220@2ndquadrant.com>
 <572A47DB.60304@gmail.com>
 <3b2f1642-7d31-f0e8-4ef1-9205d6fa5383@2ndquadrant.com>
Message-ID: <5736C475.3030405@gmail.com>
Date: Sat, 14 May 2016 09:23:49 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <3b2f1642-7d31-f0e8-4ef1-9205d6fa5383@2ndquadrant.com>
Content-Type: multipart/mixed;
 boundary="------------000103000206070908040401"
Precedence: bulk
Sender: pgsql-docs-owner@postgresql.org

This is a multi-part message in MIME format.
--------------000103000206070908040401
Content-Type: multipart/alternative;
 boundary="------------090806020803060103070402"


--------------090806020803060103070402
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

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


14.05.2016 04:41, Peter Eisentraut пишет:
> On 5/4/16 3:04 PM, Alexander Law wrote:
>> 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.
>
> 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.)
>


--------------090806020803060103070402
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">Hello Peter,<br>
      <br>
      Thank you!<br>
      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.<br>
      <br>
      Please look at the following errors/fixes.<br>
      <br>
      Patch #2 is for consistency on [1].<br>
      Bug #6 is the most interesting. Table "Table F-17. Hash Algorithm
      Speeds" on [2] contains following row:<br>
      <i>Algorithm | Hashes/sec</i><i><br>
      </i><i>crypt-bf/5 | 13504</i><br>
      And there is a following note below the table:<br>
      <i>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.)</i><br>
      It seems that the number 213 is out of sync with the table
      contents. ("Very small difference" was indeed present before [3].
      See [4].)<br>
      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).<br>
      <br>
      [1] <a class="moz-txt-link-freetext"
href="http://www.postgresql.org/docs/current/static/reference-server.html">http://www.postgresql.org/docs/current/static/reference-server.html</a><br>
      [2]
      <a class="moz-txt-link-freetext"
href="http://www.postgresql.org/docs/current/static/pgcrypto.html#PGCRYPTO-HASH-SPEED-TABLE">http://www.postgresql.org/docs/current/static/pgcrypto.html#PGCRYPTO-HASH-SPEED-TABLE</a><br>
      [3]
      <a class="moz-txt-link-freetext"
href="https://github.com/postgres/postgres/commit/d6464fdc0a591662e5e5ee1b0303932e89cb027c">https://github.com/postgres/postgres/commit/d6464fdc0a591662e5e5ee1b0303932e89cb027c</a><br>
      [4]
      <a class="moz-txt-link-freetext"
href="http://www.postgresql.org/docs/9.1/static/pgcrypto.html#PGCRYPTO-HASH-SPEED-TABLE">http://www.postgresql.org/docs/9.1/static/pgcrypto.html#PGCRYPTO-HASH-SPEED-TABLE</a><br>
      <br>
      Best regards,<br>
      Alexander<br>
      <br>
      <br>
      14.05.2016 04:41, Peter Eisentraut пишет:<br>
    </div>
    <blockquote
      cite="mid:3b2f1642-7d31-f0e8-4ef1-9205d6fa5383@2ndquadrant.com"
      type="cite">On 5/4/16 3:04 PM, Alexander Law wrote: <br>
      <blockquote type="cite">Thank you! <br>
        I have some more errors written down, maybe they are worth
        fixing too. <br>
        <br>
        Second patch is for consistency in [1]. <br>
        (I think XMLValidate could be aligned with "IS VALID predicate")
        <br>
        Third patch is for language name teared down in [1]. <br>
        It seems that root of this typo is as far as in SQL Standard
        (see M015 <br>
        description in [2]), but IMO it should be fixed anyway. <br>
      </blockquote>
      <br>
      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.) <br>
      <br>
    </blockquote>
    <br>
  </body>
</html>

--------------090806020803060103070402--

--------------000103000206070908040401
Content-Type: text/x-patch;
 name="1-pgtesttiming.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="1-pgtesttiming.patch"

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

--------------000103000206070908040401
Content-Type: text/x-patch;
 name="2-pg_xlogdump.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="2-pg_xlogdump.patch"

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>

--------------000103000206070908040401
Content-Type: text/x-patch;
 name="3-sepgpsql.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="3-sepgpsql.patch"

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>

--------------000103000206070908040401
Content-Type: text/x-patch;
 name="4-install-windows.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="4-install-windows.patch"

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.

--------------000103000206070908040401
Content-Type: text/x-patch;
 name="5-btree-gist.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="5-btree-gist.patch"

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>teodor@stack.net</email>) ,
+   Teodor Sigaev (<email>teodor@stack.net</email>),
    Oleg Bartunov (<email>oleg@sai.msu.su</email>), and
    Janko Richter (<email>jankorichter@yahoo.de</email>).  See
    <ulink url="http://www.sai.msu.su/~megera/postgres/gist/"></ulink>

--------------000103000206070908040401
Content-Type: text/x-patch;
 name="6-pgcrypto.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="6-pgcrypto.patch"

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</>

--------------000103000206070908040401
Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0


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

--------------000103000206070908040401--