Horton

Re: Large writable variables

Andres Freund <andres@anarazel.de>

View thread View on postgr.es
From: Andres Freund <andres@anarazel.de>
To: pgsql-hackers@postgresql.org, Thomas Munro <thomas.munro@enterprisedb.com>
Date: 2018-10-15T20:17:56Z
Lists: pgsql-hackers 
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

Commits

  1. Apply unconstify() in more places

  2. Improve unconstify() documentation

  3. Drop const cast from dlsym() calls

  4. Const-ify a few more large static tables.

  5. Improve tzparse's handling of TZDEFRULES ("posixrules") zone data.

  6. Avoid statically allocating statement cache in ecpglib/prepare.c.

  7. Reorder FmgrBuiltin members, saving 25% in size.

  8. Add macro to cast away const without allowing changes to underlying type.

  9. Mark constantly allocated dest receiver as const.

  10. Avoid statically allocating formatting.c's format string caches.

  11. Correct constness of system attributes in heap.c & prerequisites.

  12. Avoid statically allocating gmtsub()'s timezone workspace.

  13. Correct constness of a few variables.

  14. Move the replication lag tracker into heap memory.