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

On 2014-01-06 01:25:57 +0000, Greg Stark 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.

Abhijit Menon-Sen (CCed) has prototyped an isolationtester version that
can connect to multiple nodes. Once we've got automated setup of
multiple nodes, pursuing that makes sense again.

> > 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.

Very emphathically seconded. It should absolutely not be necessary to
use different chroots. Pretty much the only case that will require that
is tablespaces unless you do some pretty ugly hackery...

In almost all scenarios you'll have to change either
unix_socket_directory or port (recommended) in addition to the datadir -
but that's not a problem.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services