Re: can we optimize STACK_DEPTH_SLOP

Greg Stark <stark(at)mit(dot)edu> writes:
> Ok, I managed to get __atribute__((destructor)) working and capitured
> the attached pmap output for all the revisions. You can see the git
> revision in the binary name along with a putative date though in the
> case of branches the date can be deceptive. It looks to me like REL8_4
> is already bloated by REL8_4_0~2268 (which means 2268 commits *before*
> the REL8_4_0 tag -- i.e. soon after it branched).

I traced through this by dint of inserting a lot of system("pmap") calls,
and what I found out is that it's the act of setting one of the timezone
variables that does it. This is because tzload() allocates a local
variable "union local_storage ls", which sounds harmless enough, but
in point of fact the darn thing is 78K! And to add insult to injury,
with my setting (US/Eastern) there is a recursive call to parse the
"posixrules" timezone file. So that's 150K worth of stack right
there, although possibly it's only half that for some zone settings.
(And if you use "GMT" you escape all of this, since that's hard coded.)

So now I understand why the IANA code has provisions for malloc'ing
that storage rather than just using the stack. We should do likewise.

regards, tom lane