Re: In-core regression tests for replication, cascading, archiving, PITR, etc. Michael Paquier

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 <stark(at)mit(dot)edu> wrote:

--
greg
On 5 Jan 2014 14:54, "Mark Dilger" <markdilger(at)yahoo(dot)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.