Re: contrib/sepgsql regression tests are a no-go - Mailing list pgsql-hackers

From Robert Haas
Subject Re: contrib/sepgsql regression tests are a no-go
Date
Msg-id CA+TgmoYWUFMHo4bJBXdsWi==C9TTaTzzFJe9fJMhsoO65w5_Zg@mail.gmail.com
Whole thread Raw
In response to Re: contrib/sepgsql regression tests are a no-go  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: contrib/sepgsql regression tests are a no-go
List pgsql-hackers
On Tue, Sep 27, 2011 at 3:39 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I wrote:
>> I think it should be possible to still use all the existing testing
>> infrastructure if the check/test script does something like
>>       make REGRESS="label dml misc" check
>
> I've now worked through the process of actually running the sepgsql
> regression tests, and I must say that I had no idea how utterly invasive
> they were --- the idea that they could ever be part of a default "make
> check" sequence is even more ridiculous than I thought before.
>
> Accordingly, the attached patch does what I suggested above, namely dike
> out the Makefile's knowledge of how to run the regression tests and put
> it into the chkselinuxenv script.  It would be appropriate to rename that
> script to something like "test_sepgsql", but I didn't do that yet to
> reduce the displayed size of the patch.

Seems fine.  The rename is definitely needed.  We may want to
back-patch this into 9.1 to avoid the headache of dealing with this
for 5 years.

> I have not touched the documentation, either.  One thing I'd like to do
> is adjust both the SGML documentation and the hints printed by the
> script to uniformly use "sudo ...root-privileged-command..." rather than
> recommending use of "su".  I don't like the latter because it makes it
> less than clear exactly which commands require root, encourages you to
> forget to switch out of root mode, and IMO is against local policy on
> any well-run box.  I recognize however that that might be mostly my
> own preferences showing --- what do others think?

I think that's your own preference showing.  How about just telling
people to run the commands as root without specifying how they should
accomplish that?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: random isolation test failures
Next
From: Marti Raudsepp
Date:
Subject: [PATCH] Log crashed backend's query v2