Re: Let's remove DSM_INPL_NONE.

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Let's remove DSM_INPL_NONE.
Дата
Msg-id 31962.1519792222@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Let's remove DSM_INPL_NONE.  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Let's remove DSM_INPL_NONE.
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Feb 27, 2018 at 2:50 PM, Andres Freund <andres@anarazel.de> wrote:
>> What I'm concerned about isn't so much testing paths specific to
>> dynamic_shared_memory_type=none, but paths where we currently need
>> fallbacks for the case we couldn't actually allocate dynamic shared
>> memory. Which I think we at least somewhat gracefully need to deal with.

> Well, it's not very hard to just hack the code to make dsm_create()
> always fail, or fail X% of the time, if you're so inclined.  I agree
> that -c dynamic_shared_memory_type=none is a little more convenient
> than sticking something like that into the code, but I don't think
> it's sufficiently more convenient to justify keeping an option we
> don't otherwise want.

I'd be in favor of having some normally-ifdef'd-out facility for causing
failures of this kind.  (As I mentioned upthread, I do not think "always
fail" is sufficient.)  That's very different from having a user-visible
option, though.  We don't expose a GUC that enables CLOBBER_FREED_MEMORY,
to take a relevant example.

            regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Let's remove DSM_INPL_NONE.
Следующее
От: Tatsuo Ishii
Дата:
Сообщение: Re: TODO item for broken \s with libedit seems fixed