Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> 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:

   synchronous_commit = off

   fsync = off

   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.



---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Reply via email to