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