From: | Greg Stark <stark(at)mit(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: can we optimize STACK_DEPTH_SLOP |
Date: | 2016-07-06 17:42:24 |
Message-ID: | CAM-w4HPJr_bAWAmJ95Bwko6c31v6XY5hx8xyn5hL_JGO0OWP3Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jul 6, 2016 at 2:34 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Conclusion: something we did in 8.4 greatly bloated the postmaster's
> stack space consumption, to the point that it's significantly more than
> anything a normal backend does. That's surprising and scary, because
> it means the postmaster is *more* exposed to stack SIGSEGV than most
> backends. We need to find the cause, IMO.
Hm. I do something based on your test where I build a .so and started
the postmaster with -c shared_preload_libraries to load it. I tried to
run it on every revision I have built for the historic benchmarks.
That only worked as far back as 8.4.0 -- which makes me suspect it's
possibly because of precisely shared_preload_libraries and the dynamic
linker that the stack size grew....
The only thing it actually revealed was a *drop* of 50kB between
REL9_2_0~1610 and REL9_2_0~1396.
REL8_4_0~1702 188K
REL8_4_0~1603 192K
REL8_4_0~1498 188K
REL8_4_0~1358 192K
REL8_4_0~1218 184K
REL8_4_0~1013 188K
REL8_4_0~996 192K
REL8_4_0~856 192K
REL8_4_0~775 192K
REL8_4_0~567 192K
REL8_4_0~480 188K
REL8_4_0~360 188K
REL8_4_0~151 188K
REL9_0_0~1855 188K
REL9_0_0~1654 188K
REL9_0_0~1538 192K
REL9_0_0~1454 184K
REL9_0_0~1351 184K
REL9_0_0~1249 188K
REL9_0_0~1107 184K
REL9_0_0~938 184K
REL9_0_0~627 184K
REL9_0_0~414 184K
REL9_0_0~202 184K
REL9_1_0~1867 188K
REL9_1_0~1695 184K
REL9_1_0~1511 188K
REL9_1_0~1328 192K
REL9_1_0~978 192K
REL9_1_0~948 188K
REL9_1_0~628 188K
REL9_1_0~382 192K
REL9_2_0~1825 184K
REL9_2_0~1610 192K
<--------------- here
REL9_2_0~1396 148K
REL9_2_0~1226 148K
REL9_2_0~1190 148K
REL9_2_0~1072 140K
REL9_2_0~1071 144K
REL9_2_0~984 144K
REL9_2_0~777 144K
REL9_2_0~767 148K
REL9_2_0~551 148K
REL9_2_0~309 144K
REL9_3_0~1509 148K
REL9_3_0~1304 148K
REL9_3_0~1099 144K
REL9_3_0~1030 144K
REL9_3_0~944 140K
REL9_3_0~789 144K
REL9_3_0~735 148K
REL9_3_0~589 144K
REL9_3_0~390 148K
REL9_3_0~223 144K
REL9_4_0~1923 148K
REL9_4_0~1894 148K
REL9_4_0~1755 144K
REL9_4_0~1688 144K
REL9_4_0~1617 144K
REL9_4_0~1431 144K
REL9_4_0~1246 144K
REL9_4_0~1142 148K
REL9_4_0~995 148K
REL9_4_0~744 140K
REL9_4_0~462 148K
REL9_5_0~2370 148K
REL8_4_22 192K
REL9_5_0~2183 148K
REL9_5_0~1996 148K
REL9_5_0~1782 144K
REL9_5_0~1569 148K
REL9_5_0~1557 144K
REL9_5_ALPHA1-20-g7b156c1 144K
REL9_5_ALPHA1-299-g47ebbdc 144K
REL9_5_ALPHA1-489-ge06b2e1 144K
REL9_0_23 188K
REL9_1_19 192K
REL9_2_14 144K
REL9_3_10 148K
REL9_4_5 148K
REL9_5_ALPHA1-683-ge073490 144K
REL9_5_ALPHA1-844-gdfcd9cb 148K
REL9_5_0 148K
REL9_5_ALPHA1-972-g7dc09c1 144K
REL9_5_ALPHA1-1114-g57a6a72 148K
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2016-07-06 19:43:11 | Re: primary_conninfo missing from pg_stat_wal_receiver |
Previous Message | Alvaro Herrera | 2016-07-06 17:38:13 | Re: primary_conninfo missing from pg_stat_wal_receiver |