Re: Large writable variables

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