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

From: Greg Stark <stark(at)mit(dot)edu>
To: Mark Dilger <markdilger(at)yahoo(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: In-core regression tests for replication, cascading, archiving, PITR, etc. Michael Paquier
Date: 2014-01-06 01:25:57
Message-ID: CAM-w4HMOWoA77j+8-BbzwZk-6sfJmJC1W9Ybd789JqtaCBQn1A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2014-01-06 02:13:03 Re: In-core regression tests for replication, cascading, archiving, PITR, etc. Michael Paquier
Previous Message Andres Freund 2014-01-05 20:58:00 Re: [PATCH] SQL assertions prototype