Hi, On 2018-10-15 13:07:54 -0700, Andres Freund wrote: > top itialized allocations: > $ nm -t d --size-sort -r -S src/backend/postgres|grep '\b[dD]\b'|head > 0000000008086944 0000000000087904 D fmgr_builtins > 0000000008201120 0000000000017280 d ConfigureNamesInt > 0000000008218400 0000000000013680 d ConfigureNamesBool > 0000000008189248 0000000000008512 d ConfigureNamesString > 0000000008077344 0000000000007040 D ScanKeywords > 0000000008184928 0000000000004320 d ConfigureNamesEnum > 0000000008197760 0000000000003360 d ConfigureNamesReal > 0000000008062976 0000000000002304 d DCH_keywords > 0000000008069952 0000000000002016 D pg_wchar_table > 0000000008075552 0000000000001776 d encoding_match_list > > fmgr_builtins isn't readonly even though declared a const - I assume > because it's full of addresses that will be mapped differently from > execution to execution. > > ConfigureNames* isn't marked as const, because we update them: > /* Rather than requiring vartype to be filled in by hand, do > this: */ > conf->gen.vartype = PGC_BOOL; > > I'm unclear as to why ScanKeywords, DCH_keywords aren't in a readonly > section.
It's because they contain pointers to strings, which are affected by relocations (and position independent executables force everything to be relocatable). They do go into .data.rel.ro however: $ objdump -t ~/build/postgres/dev-optimize/vpath/src/backend/postgres|grep -E '\b(ScanKeywords|fmgr_builtins|DCH_keywords|pg_wchar_table)\b' 00000000007b0800 l O .data.rel.ro 0000000000000900 DCH_keywords 00000000007b4020 g O .data.rel.ro 0000000000001b80 ScanKeywords 00000000007b65a0 g O .data.rel.ro 0000000000015760 fmgr_builtins 00000000007b2340 g O .data.rel.ro 00000000000007e0 pg_wchar_table as long as we're using forking rather than EXEC_BACKEND, that's perfectly fine. I don't quite know how windows handles any of this, so I can't say whether it's a problem there. Greetings, Andres Freund
