On Tue, Feb 27, 2018 at 02:53:55PM -0500, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
>> On 2018-02-27 14:41:47 -0500, Tom Lane wrote:
>>> What I didn't understand about it was what kind of testing this'd make
>>> harder. If we desupport dynamic_shared_memory_type=none, there aren't
>>> any code paths that need to cope with the case, and we should just
>>> remove any code that thereby becomes unreachable.
>
>> 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.
>
> Ah. That's a fair point, but I do not think
> dynamic_shared_memory_type=none is a good substitute for having a way to
> provoke allocation failures. That doesn't let you test recovery from
> situations where your first allocation works and second one fails, for
> example; and cleanup from that sort of case is likely to be more
> complicated than the trivial case.
dynamic_shared_memory_type is used in six code paths where it is aimed
at doing sanity checks:
- Mute DSM initialization at postmaster startup.
- Mute cleanup of previous DSM segments from a past postmaster.
- Block backend startup if there is no DSM.
- Mute parallel query in planner.
- Mute parallel query for parallel btree builds.
- Mute creation of parallel contexts in executor.
The point is that there are other control mechanisms for each one of
them. Mainly, for the executor portion, the number of workers is
controlled by other GUCs on planner-side.
--
Michael