The reason I was going to all the trouble of creating chrooted environments was to be able to replicate clusters that have tablespaces. Not doing so makes the test code simpler at the expense of reducing test coverage.
I am using the same binaries. The chroot directories are not "chroot jails". I'm intentionally bind mounting out to all the other directories on the system, except the other clusters' data directories and tablespace directories. The purpose of the chroot is to make the paths the same on all clusters without the clusters clobbering each other. So: (the '->' means "is bind mounted to") /master/bin -> /bin /master/dev -> /dev /master/etc -> /etc /master/lib -> /lib /master/usr -> /usr /master/data /master/tablespace /hotstandby/bin -> /bin /hotstandby/dev -> /dev /hotstandby/etc -> /etc /hotstandby/lib -> /lib /hotstandby/usr -> /usr /hotstandby/data /hotstandby/tablespace So from inside the master chroot, you see the system's /bin as /bin, the system's /dev as /dev, etc, but what you see as /data and /tablespace are your own private ones. Likewise from the hotstandby chroot. But since the binaries are in something like /home/myuser/postgresql/src/test/regress/tmp_check/install/usr/local/pgsql/bin each cluster uses the same binaries, refered to by the same path. On Sunday, January 5, 2014 5:25 PM, Greg Stark <st...@mit.edu> wrote: -- greg On 5 Jan 2014 14:54, "Mark Dilger" <markdil...@yahoo.com> wrote: > > I am building a regression test system for replication and came across > this email thread. I have gotten pretty far into my implementation, but > would be happy to make modifications if folks have improvements to > suggest. If the community likes my design, or a modified version based > on your feedback, I'd be happy to submit a patch. This sounds pretty cool. The real trick will be in testing concurrent behaviour -- I.e. queries on the slave when it's replaying logs at a certain point. But right now we have nothing so anything would be an improvement. > This is possible all on one system because the database clusters > are chroot'ed to see their own /data directory and not the /data directory > of the other chroot'ed clusters, although the rest of the system, like /bin > and /etc and /dev are all bind mounted and visible to each cluster. This isn't necessary. You can use the same binaries and run initdb with a different location just fine. Then start up the database with -D to specify the directory.