Re: Let's remove DSM_INPL_NONE. - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Let's remove DSM_INPL_NONE.
Date
Msg-id 31962.1519792222@sss.pgh.pa.us
Whole thread Raw
In response to Re: Let's remove DSM_INPL_NONE.  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Let's remove DSM_INPL_NONE.
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: Let's remove DSM_INPL_NONE.
Next
From: Tatsuo Ishii
Date:
Subject: Re: TODO item for broken \s with libedit seems fixed