Thread: 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
Attachment
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 >
Attachment
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 >
Attachment
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 пишет:
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 пишет:
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.)
Attachment
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