-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
I thought the goal here was to have a testing framework that (a) is
portable to every platform we support and (b) doesn't require root
privileges to run. None of those options sound like they'll help meet
those requirements.
FWIW, I
Michael Paquier wrote:
A possible input for a test that users could provide would be something like
that:
# Node information for tests
nodes {
{node1, postgresql.conf params, recovery.conf params}
{node2, postgresql.conf params, recovery.conf params, slave of node1}
}
# Run test
On Thu, Jan 9, 2014 at 12:34 PM, Mark Dilger markdil...@yahoo.com wrote:
Michael Paquier wrote:
A possible input for a test that users could provide would be something
like that:
# Node information for tests
nodes {
{node1, postgresql.conf params, recovery.conf params}
{node2,
On 01/06/2014 07:12 PM, Mark Dilger wrote:
The reason I was going to all the trouble of creating
chrooted environments was to be able to replicate
clusters that have tablespaces.
You can remove and recreate the symlink in pg_tblspc directory, after
creating the cluster, to point it to a
Heikki Linnakangas hlinnakan...@vmware.com writes:
Another idea would be to do something like chroot, but more lightweight,
using FUSE, private mount namespaces, or cgroups.
I thought the goal here was to have a testing framework that (a) is
portable to every platform we support and (b)
On 2014-01-07 10:27:14 -0500, Tom Lane wrote:
Heikki Linnakangas hlinnakan...@vmware.com writes:
Another idea would be to do something like chroot, but more lightweight,
using FUSE, private mount namespaces, or cgroups.
I thought the goal here was to have a testing framework that (a) is
On Tuesday, January 7, 2014 7:29 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Heikki Linnakangas hlinnakan...@vmware.com writes:
Another idea would be to do something like chroot, but more lightweight,
using FUSE, private mount namespaces, or cgroups.
I thought the goal here was to have a
Mark Dilger markdil...@yahoo.com writes:
Would it make sense for this to just be part of 'make check'?
Probably not, as (I imagine) it will take quite a bit longer than
make check does today. People who are not working on replication
related features will be annoyed if a test cycle starts
On 01/05/2014 09:13 PM, Michael Paquier wrote:
On Mon, Jan 6, 2014 at 4:51 AM, Mark Dilger markdil...@yahoo.com
mailto: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
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 agree that merely setting up masters and slaves is
the tip of the iceberg. It seems to be what needs
to be tackled first, though, because until we have
a common framework, we cannot all contribute
tests to it.
I imagine setting up a whole hierarchy of master,
hotstandbys, warmstandbys, etc.,
On 2014-01-06 09:12:03 -0800, Mark Dilger wrote:
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
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
On Mon, Jan 6, 2014 at 4:51 AM, 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.
14 matches
Mail list logo
