On Mon, Mar 27, 2017 at 11:47 PM, Thomas Munro <thomas.mu...@enterprisedb.com> wrote: > Couldn't cleanup code continue to work just the same way though? The > only extra structure is an intrusive freelist, but that could be > completely ignored by code that wants to scan the whole array after > crash. It would only be used to find a free slot after successful > restart, once the freelist is rebuilt and known to be sane, and could > be sanity checked when accessed by dsm_create. So idea 2 doesn't seem > to make that code any less robust, does it?
Agreed. > Deterministic key_t values for SysV IPC do seem problematic thought, > for multiple PostgreSQL clusters. Maybe that is a serious problem for > idea 1. It might be. Mostly, even if we had no PostgreSQL-imposed limits here at all, I don't share your confidence that we create tons of DSM segments and everything will just work. I think we'll run into operating system limits pretty quickly -- either hard limits, like limits on the number of segments supported, or soft limits, like difficulties handling large numbers of memory mappings with good performance. I personally think it would be more worthwhile to work on http://postgr.es/m/ca+tgmozvqxatogekfdng_smugx_it8_b4l0okjzeowhburm...@mail.gmail.com instead, but I will be a little too busy to write that patch this week. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
