| From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Andreas Karlsson <andreas(at)proxel(dot)se>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Improving test coverage of extensions with pg_dump |
| Date: | 2015-09-03 01:35:49 |
| Message-ID: | CAB7nPqR_zj7Q_6gjC+vmLid8bt1aWAXp5hvHny65MOUb1gKufw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Sep 3, 2015 at 12:38 AM, Andres Freund wrote:
> Isn't a full test with a separate initdb, create extension etc. a really
> heavyhanded way to test this? I mean that's a test where the setup takes
> up to 10s, whereas the actual runtime is in the millisecond range?
>
> Adding tests in this manner doesn't seem scalable to me.
How to include such kind of tests is in the heart of the discussion
since this patch has showed up. I think we are now close to 5
different opinions with 4 different hackers on the matter, the Riggs'
theorem applies nicely.
> I think we should rather add *one* test that does dump/restore over the
> normal regression test database. Something similar to the pg_upgrade
> tests. And then work at adding more content to the regression test
> database - potentially sourcing from src/test/modules.
If you are worrying about run time, pg_upgrade already exactly does
that. What would be the point to double the amount of time to do the
same thing in two different places?
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Stark | 2015-09-03 01:44:04 | Re: Allow a per-tablespace effective_io_concurrency setting |
| Previous Message | Michael Paquier | 2015-09-03 01:20:12 | Re: Improving test coverage of extensions with pg_dump |