Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>
>> I have some ideas about testing configuration items. Doing all our tests
>> with the default config is not ideal, I think. Essentially we'd put up a
>> server that would have sets of <branch, list-of-config-lines>. The
>> client would connect to the server if it could and get the set(s) of
>> lines for the branch on question, and for each set it would try another
>> run of installcheck (I'm also wondering if we should switch to doing
>> installcheck-parallel). Anyway, this would be a config option on the
>> buildfarm, so we wouldn't overburden hosts with limited run windows
>> (e.g. the Solaris boxes Sun has on the farm) or slow run times (e.g.
>> some of the old and/or tiny hardware we have).
>>
>
>
>> If this seems worth it I'll put it on my TODO.
>>
>
> Sounds like a good plan, except that an extra server seems unnecessary
> mechanism (and perhaps an unnecessary security risk). We can just put
> a file into CVS src/test/regress showing what we'd like tested.
>
>
>
That could work.
Let's say that this file looks just like a postgresql.conf file, except
that any line beginning with '[<identifier]>' is a config set name for
the lines that follow. So we might have:
[asynch_commit] synchronous_commit = off
[no_fsync] fsync = off
[csvlogs] start_log_collector = true log_destination = 'stderr, csvlog'
Then there would be an extra installcheck-parallel run for each set. If
the file isn't there we do nothing.
cheers
andrew
