A Java/Javascript-based testing framework has been published: https://github.com/clustertest/clustertest-framework A branch of the Slony code has been set up that intends to provide tests based on this framework. https://github.com/ssinger/slony1-engine/tree/clustertest This is intended to eventually supplant all the tests currently found in: a) src/ducttape http://git.postgresql.org/gitweb?p=slony1-engine.git;a=tree;f=src/ducttape These tests haven't been touched for other than GIT/CVS conversion since 2008, and are notably painful to run in an automated fashion as they have somewhat intricate dependancies on X, and really expect to be controlled manually. b) tests http://git.postgresql.org/gitweb?p=slony1-engine.git;a=tree;f=tests These tests are more up to date, having been regularly maintained, and have the not inconsiderable merit that they were designed to be run as self-contained individual tests. Unfortunately, they do very little to test concurrency issues, and while they're fine for providing "unit test" functionality to validate that specific conditions attending bugs do not regress over time, they're not good for validating complex/concurrency test scenarios. The new framework is intended to replace both sets of tests shown above.
Chris proposes the following patch: https://github.com/cbbrowne/slony1-engine/commit/e919dfd92f8463fbe6f8e4d1f393369489b38e3c 1. Ignore generated files (logs and such) 2. DB properties file is provided as a sample, so we aren't trying to overwrite, from the build, the user's version
Minor gripe: Why do we have separate paths for binaries for each database? It's irritating two ways: a) The path has to get set 5 times b) It seems to me that having different versions used by different DBs is asking for trouble, no?
(In reply to comment #2) > Minor gripe: Why do we have separate paths for binaries for each database? > It's irritating two ways: > > a) The path has to get set 5 times > b) It seems to me that having different versions used by different DBs is > asking for trouble, no? You might want to run different versions of postgresql for each database. We might be able to come up with a way of having a default value and the overriding it.
Committed to MASTER