Re: Some minor error fixes

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

On 4/18/16 1:30 AM, Alexander Law wrote:
> Please consider fixing some more minor errors.
> Patches attached.

fixed

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

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

04.05.2016 04:10, Peter Eisentraut пишет:
> On 4/18/16 1:30 AM, Alexander Law wrote:
>> Please consider fixing some more minor errors.
>> Patches attached.
>
> fixed
>

On 5/4/16 10:40 AM, Alexander Law wrote:
> 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.

fixed

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

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

04.05.2016 21:11, Peter Eisentraut пишет:
> On 5/4/16 10:40 AM, Alexander Law wrote:
>> 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.
>
> fixed
>

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.)

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

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.)
>

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.)
>

On 5/14/16 2:23 AM, Alexander Law wrote:
> 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?

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

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

15.07.2016 05:36, Peter Eisentraut пишет:
> On 5/14/16 2:23 AM, Alexander Law wrote:
>> 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?
>

On 7/15/16 12:06 AM, Alexander Law wrote:
> 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).

makes sense, fixed

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