From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Regression tests vs existing users in an installation |
Date: | 2016-07-18 16:58:45 |
Message-ID: | 8260.1468861125@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> writes:
> On 7/15/16 6:13 PM, Tom Lane wrote:
>> We've talked before about how the regression tests should be circumspect
>> about what role names they create/drop, so as to avoid possibly blowing
>> up an installation's existing users during "make installcheck".
> I'm not particularly sure that that is a useful goal anymore. Setting
> up a new instance is cheap, so if users are concerned, they should not
> run the tests against their important instance.
To my mind, the main point of "make installcheck" is to verify that
your actual installation, not some other instance, is working right.
This is far from a trivial issue; for instance on a SELinux machine,
you need to be able to verify that the installed policy allows the
DB to work, and that is very likely to be path-sensitive.
So this remains an important requirement to me. It's true that it might
be something you need to run only right after making the installation ---
but that doesn't mean the DB is empty. Consider wanting to test a freshly
pg_upgrade'd installation, for example.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2016-07-18 18:33:14 | Re: rethinking dense_alloc (HashJoin) as a memory context |
Previous Message | Magnus Hagander | 2016-07-18 16:50:15 | Re: Typos in logical decoding |