On Tue, Feb 6, 2018 at 8:34 PM, Kyotaro HORIGUCHI <horiguchi.kyot...@lab.ntt.co.jp> wrote: > Based on the reason, it fails to run when > dynamic_shared_memory_type = none and it is accompanied by > several cleanup complexities. The decision there is we should go > for just using static shared memory rather than adding complexity > for nothing. If it really needs to be expandable in the future, > it's the time to use DSA. (But would still maintain a fallback > stuff.)
It seems to me that there was a thread where Tom proposed removing support for dynamic_shared_memory_type = none. The main reason that I included that option initially was because it seemed silly to risk causing problems for users whose dynamic shared memory facilities didn't work for the sake of a feature that, at the time (9.4), had no in-core users. But things have shifted a bit since then. We have had few complaints about dynamic shared memory causing portability problems (except for performance: apparently some implementations perform better than others on some systems, and we need support for huge pages, but neither of those things are a reason to disable it) and we now have in-core use that is enabled by default. I suggest we remove support for dynamic_shared_memory_type = none first, and see if we get any complaints. If we don't, then future patches can rely on it being present. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
