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:
[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
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
