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

On Tuesday, January 7, 2014 7:29 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
Heikki Linnakangas <hlinnakangas(at)vmware(dot)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) doesn't require root
privileges to run.  None of those options sound like they'll help meet
those requirements.

            regards, tom lane

If I drop the idea of sudo/chroot and punt for now on testing
tablespaces under replication, it should be possible to test
the rest of the replication system in a way that meets (a) and
(b).  Perhaps Andres' idea of tablespaces relative to the
data directory will get implemented some day, at which point
we wouldn't be punting quite so much.  But until then, punt.

Would it make sense for this to just be part of 'make check'?
That would require creating multiple database clusters under
multiple data directories, and having them bind to multiple
ports or unix domain sockets.  Is that a problem?

What's the logic of having replication testing separated from
the other pg_regress tests?  Granted, not every user of postgres
uses replication, but that's true for lots of features, and
we don't split things like json into separate test suites.
Vendors who run 'make check' as part of their packaging of
postgresql would probably benefit from knowing if replication
doesn't work on their distro, and they may not change their
packaging systems to include a second 'make replicationcheck'
step.

mark