Re: Testing the async-commit patch

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