| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Mark Dilger <markdilger(at)yahoo(dot)com> |
| Cc: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Greg Stark <stark(at)mit(dot)edu>, 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-07 22:02:09 |
| Message-ID: | 20590.1389132129@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Mark Dilger <markdilger(at)yahoo(dot)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 taking 10X
longer than it used to, for tests of no value to them.
It's already not the case that "make check" runs every available
automated test; the isolation tests, the PL tests, the contrib
tests are all separate.
There is a make check-world, which I think should reasonably run
all of these.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kevin Grittner | 2014-01-07 22:27:38 | Re: Re: How to reproduce serialization failure for a read only transaction. |
| Previous Message | Mark Dilger | 2014-01-07 21:41:32 | Re: In-core regression tests for replication, cascading, archiving, PITR, etc. Michael Paquier |