Thread: Fix typos and inconsistencies for HEAD (take 7)
Hello hackers, Please consider fixing the next pack of typos and inconsistencies in the tree: 7.1. h04m05s06 -> h04mm05s06 (in fact it's broken since 6af04882, but h04mm05s06.789 still accepted) 7.2. hasbucketcleanup -> hashbucketcleanup 7.3. _hashm_spare -> hashm_spares 7.4. hashtbl -> hash table 7.5. HAS_RELFILENODES -> XINFO_HAS_RELFILENODES 7.6. HAS_SUBXACT -> XINFO_HAS_SUBXACT 7.7. HAVE_FCVT -> remove (survived after ff4628f3) 7.8. HAVE_FINITE -> remove (orphaned after cac2d912) 7.9. HAVE_STRUCT_SOCKADDR_UN -> remove (not used since introduction in 399a36a7) 7.10. HAVE_SYSCONF -> remove (survived after ff4628f3) 7.11. HAVE_ZLIB -> HAVE_LIBZ 7.12. HEAP_CLEAN -> XLOG_HEAP2_CLEAN 7.13. HEAP_CONTAINS_NEW_TUPLE_DATA -> XLH_UPDATE_CONTAINS_NEW_TUPLE, XLOG_HEAP_CONTAINS_OLD_TUPLE -> XLH_UPDATE_CONTAINS_OLD_TUPLE, XLOG_HEAP_CONTAINS_OLD_KEY -> XLH_UPDATE_CONTAINS_OLD_KEY, XLOG_HEAP_PREFIX_FROM_OLD -> XLH_UPDATE_PREFIX_FROM_OLD, XLOG_HEAP_SUFFIX_FROM_OLD -> XLH_UPDATE_SUFFIX_FROM_OLD (renamed in 168d5805) 7.14. HEAP_FREEZE -> FREEZE_PAGE (an inconsistency since introduction in 48188e16) 7.15. heapio.c -> hio.c 7.16. heap_newpage -> XLOG_FPI (orphaned since 54685338) 7.17. heaxadecimal -> hexadecimal 7.18. hostlen -> nodelen, host -> node, serv -> service, servlen -> servicelen 7.19. i386s -> x86_64 7.20. IConst/FConst -> ICONST/FCONST 7.21. imit -> limit 7.22. IN_ARCHIVE_RECOVERY -> DB_IN_ARCHIVE_RECOVERY 7.23. ind_arraysize, ind_value -> ind_arrsize, ind_pointer 7.24. index_getnext -> index_getnext_slot 7.25. IndexTupleVector -> IndexTuple vector 7.26. innerConsistent -> innerConsistentFn 7.27. in-progres -> in-progress 7.28. inspire with -> inspired by the (sync with 192b0c94) 7.29. internalerrpos -> internalerrposition 7.30. internal_procname -> internal_proname 7.31. interruptOK -> remove (orphaned after d0699571) 7.32. intratransaction -> intra-transaction 7.33. InvalidOffset -> InvalidOffsetNumber 7.34. invtrans -> invtransfn 7.35. isbuiltin -> fmgr_isbuiltin 7.36. iself -> itself 7.37. isnoinherit -> noinherit 7.38. ISO_DATES -> USE_ISO_DATES 7.39. isParentRoot -> remove (orphaned after 218f5158) 7.40. isPrefix -> prefix 7.41. ItemPointerIsMax -> remove (orphaned after e20c70cb) 7.42. itemsin -> items in 7.43. jbVal -> jbval 7.44. json_plperl -> jsonb_plperlu 7.45. jvbBinary -> jbvBinary 7.46. keyAttrs -> attrKind 7.47. keyinfo -> key info 7.48. key_modified -> key_changed 7.49. killitems -> killedItems 7.50. KnownAssignedTransactions -> KnownAssignedTransactionIds Also, I found e-mail headers in optimizer/plan/README not relevant, so I propose to remove them. And another finding is related to the sleep effective resolution. `man 7 time` says "Since kernel 2.6.13, the HZ value is a kernel configuration parameter and can be 100, 250 (the default) ...", so the 10 milliseconds is not the most common effective resolution nowadays. I propose the corresponding patch for pgsleep.c, but we have a similar statement in doc/.../config.sgml. I think It should be fixed too. Best regards, Alexander
Attachment
Alexander Lakhin <exclusion@gmail.com> writes:
> Also, I found e-mail headers in optimizer/plan/README not relevant, so I
> propose to remove them.
FWIW, I think they're highly relevant, because they put a date on
that text. I've not gone through that README lately, but I wouldn't
be surprised if it's largely obsolete --- it hasn't been maintained
in any meaningful way since Vadim wrote it. Without the headers, a
reader would have no warning of that.
What really ought to happen, likely, is for somebody to extract
whatever is still useful there into a new(?) section in the parent
directory's README.
regards, tom lane
On Sun, Jul 21, 2019 at 08:28:53AM +0300, Alexander Lakhin wrote: > Please consider fixing the next pack of typos and inconsistencies in the > tree: Thanks, all those things look fine. I have noticed one mistake. > 7.44. json_plperl -> jsonb_plperlu The path was incorrect here. > Also, I found e-mail headers in optimizer/plan/README not relevant, so I > propose to remove them. Not sure about that part. > And another finding is related to the sleep effective resolution. `man 7 > time` says "Since kernel 2.6.13, the HZ value is a kernel configuration > parameter and can be 100, 250 (the default) ...", so the 10 > milliseconds is not the most common effective resolution nowadays. > I propose the corresponding patch for pgsleep.c, but we have a similar > statement in doc/.../config.sgml. I think It should be fixed too. Fixing both places sounds adapted to me. An alternative we could use here is just to say something like that: The effective resolution is only 1/HZ, which can be configured with kernel parameter (see man 7 time), and is 4 milliseconds by default. -- Michael
Attachment
Michael Paquier <michael@paquier.xyz> writes:
> On Sun, Jul 21, 2019 at 08:28:53AM +0300, Alexander Lakhin wrote:
>> And another finding is related to the sleep effective resolution. `man 7
>> time` says "Since kernel 2.6.13, the HZ value is a kernel configuration
>> parameter and can be 100, 250 (the default) ...", so the 10
>> milliseconds is not the most common effective resolution nowadays.
>> I propose the corresponding patch for pgsleep.c, but we have a similar
>> statement in doc/.../config.sgml. I think It should be fixed too.
> Fixing both places sounds adapted to me. An alternative we could use
> here is just to say something like that:
> The effective resolution is only 1/HZ, which can be configured with
> kernel parameter (see man 7 time), and is 4 milliseconds by
> default.
Whatever we say here is going to be a lie on some platforms.
Probably best just to say that the sleep resolution is platform-dependent
and leave it at that.
regards, tom lane
Hello Michael, 22.07.2019 4:05, Michael Paquier wrote: >> Also, I found e-mail headers in optimizer/plan/README not relevant, so I >> propose to remove them. > Not sure about that part. I agree that the proposed fix is not complete, but just raises the demand for a subsequent fix. If you don't mind, I would return to such questionable and aside items after finishing with the unicums en masse. Best regards. Alexander
Hello Tom,
22.07.2019 7:14, Tom Lane wrote:
22.07.2019 7:14, Tom Lane wrote:
I think, we can say "on many systems"/ "on most Unixen", and it would not be a lie.Fixing both places sounds adapted to me. An alternative we could use here is just to say something like that: The effective resolution is only 1/HZ, which can be configured with kernel parameter (see man 7 time), and is 4 milliseconds by default.Whatever we say here is going to be a lie on some platforms. Probably best just to say that the sleep resolution is platform-dependent and leave it at that.
In my opinion, while a generic reference to platform-dependency is OK for developer' documentation, it makes the following passage in config.sgml vague (we don't give user a hint, what "the effective resolution" can be - several seconds/milliseconds/nanoseconds?):
The default value is 200 milliseconds (<literal>200ms</literal>). Note that on many systems, the
effective resolution of sleep delays is 10 milliseconds; setting
<varname>bgwriter_delay</varname> to a value that is not a multiple of 10
might have the same results as setting it to the next higher multiple of 10.
->
The default value is 200 milliseconds (<literal>200ms</literal>). Note that the
effective resolution of sleep delays is paltform-dependent. setting
<varname>bgwriter_delay</varname> to a value that is not a multiple of the effective resolution,
might have the same results as setting it to the next higher multiple.
Best regards,
Alexander