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
--
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
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 пишет:
Show quoted text
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
--
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
Thank you!
I have some more errors written down, maybe they are worth fixing too.
Second patch is for consistency in [1]http://www.postgresql.org/docs/9.5/static/unsupported-features-sql-standard.html.
(I think XMLValidate could be aligned with "IS VALID predicate")
Third patch is for language name teared down in [1]http://www.postgresql.org/docs/9.5/static/unsupported-features-sql-standard.html.
It seems that root of this typo is as far as in SQL Standard (see M015
description in [2]http://jtc1sc32.org/doc/N1501-1550/32N1529T-text%20for%20FCD%209075-9.pdf), but IMO it should be fixed anyway.
[1]: http://www.postgresql.org/docs/9.5/static/unsupported-features-sql-standard.html
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
http://jtc1sc32.org/doc/N1501-1550/32N1529T-text%20for%20FCD%209075-9.pdf
04.05.2016 21:11, Peter Eisentraut пишет:
Show quoted text
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
--
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
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]http://www.postgresql.org/docs/current/static/reference-server.html.
Bug #6 is the most interesting. Table "Table F-17. Hash Algorithm
Speeds" on [2]http://www.postgresql.org/docs/current/static/pgcrypto.html#PGCRYPTO-HASH-SPEED-TABLE 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]https://github.com/postgres/postgres/commit/d6464fdc0a591662e5e5ee1b0303932e89cb027c. See [4]http://www.postgresql.org/docs/9.1/static/pgcrypto.html#PGCRYPTO-HASH-SPEED-TABLE.)
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
http://www.postgresql.org/docs/current/static/pgcrypto.html#PGCRYPTO-HASH-SPEED-TABLE
[3]: https://github.com/postgres/postgres/commit/d6464fdc0a591662e5e5ee1b0303932e89cb027c
https://github.com/postgres/postgres/commit/d6464fdc0a591662e5e5ee1b0303932e89cb027c
[4]: 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
Best regards,
Alexander
14.05.2016 04:41, Peter Eisentraut пишет:
Show quoted text
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]http://www.postgresql.org/docs/current/static/reference-server.html.
Bug #6 is the most interesting. Table "Table F-17. Hash Algorithm
Speeds" on [2]http://www.postgresql.org/docs/current/static/pgcrypto.html#PGCRYPTO-HASH-SPEED-TABLE 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]https://github.com/postgres/postgres/commit/d6464fdc0a591662e5e5ee1b0303932e89cb027c. See [4]http://www.postgresql.org/docs/9.1/static/pgcrypto.html#PGCRYPTO-HASH-SPEED-TABLE.)
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
http://www.postgresql.org/docs/current/static/pgcrypto.html#PGCRYPTO-HASH-SPEED-TABLE
[3]: https://github.com/postgres/postgres/commit/d6464fdc0a591662e5e5ee1b0303932e89cb027c
https://github.com/postgres/postgres/commit/d6464fdc0a591662e5e5ee1b0303932e89cb027c
[4]: 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
Best regards,
Alexander
14.05.2016 04:41, Peter Eisentraut пишет:
Show quoted text
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.)
Attachments:
1-pgtesttiming.patchtext/x-patch; name=1-pgtesttiming.patchDownload+1-1
2-pg_xlogdump.patchtext/x-patch; name=2-pg_xlogdump.patchDownload+1-1
3-sepgpsql.patchtext/x-patch; name=3-sepgpsql.patchDownload+2-2
4-install-windows.patchtext/x-patch; name=4-install-windows.patchDownload+1-1
5-btree-gist.patchtext/x-patch; name=5-btree-gist.patchDownload+1-1
6-pgcrypto.patchtext/x-patch; name=6-pgcrypto.patchDownload+1-1
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
--
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
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?
--
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
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
--
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs