On Mon, Mar 27, 2017 at 11:47 PM, Thomas Munro
<thomas.munro@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_B4L0OKJZeowHburMkiQ@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