Re: Convert node test compile-time settings into run-time parameters

Peter Eisentraut <peter@eisentraut.org> writes:
> Ok, I have an improved plan.  I'm wrapping all the code related to this 
> in #ifdef DEBUG_NODE_TESTS_ENABLED.  This in turn is defined in 
> assert-enabled builds, or if you define it explicitly, or if you define 
> one of the legacy individual symbols.  That way you get the run-time 
> settings in a normal development build, but there is no new run-time 
> overhead.  This is the same scheme that we use for debug_discard_caches.

+1; this addresses my concern about not adding effectively-dead code
to production builds.  Your point upthread about debug_print_plan and
other legacy debug switches was not without merit; should we also fold
those into this plan?  (In that case we'd need a symbol named more
generically than DEBUG_NODE_TESTS_ENABLED.)

> (An argument could be made to enable this code if and only if assertions 
> are enabled, since these tests are themselves kind of assertions.  But I 
> think having a separate symbol documents the purpose of the various code 
> sections better.)

Agreed.

>> Maybe not three settings, but a single setting, with multiple values, like
>> debug_io_direct?

> Yeah, good idea.  Let's get some more feedback on this before I code up 
> a complicated list parser.

Kinda doubt it's worth the trouble, either to code the GUC support or
to use it.  I don't object to having the booleans in a debug build,
I was just concerned about whether they should exist in production.

            regards, tom lane