Robert Haas wrote:
On Tue, Sep 27, 2011 at 6:30 PM, Tom Lane wrote:
If I have to break up the recipe with annotations like "run this part as
root" and then "these commands no longer need root", I don't think
that's going to be an improvement over either of the above.
Fair enough, I'm not g
On Tue, Sep 27, 2011 at 6:30 PM, Tom Lane wrote:
>>> 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 "
Robert Haas writes:
> On Tue, Sep 27, 2011 at 3:39 PM, Tom Lane wrote:
>> 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.
> Seems fine. The rename is definite
On Tue, Sep 27, 2011 at 3:39 PM, Tom Lane 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
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 n
2011/9/26 Tom Lane :
> Kohei KaiGai writes:
>> How about this fix on regression test of sepgsql?
>
> IMO, the fundamental problem with the sepgsql regression tests is that
> they think they don't need to play by the rules that apply to every
> other PG regression test. I don't think this patch is
Kohei KaiGai writes:
> How about this fix on regression test of sepgsql?
IMO, the fundamental problem with the sepgsql regression tests is that
they think they don't need to play by the rules that apply to every
other PG regression test. I don't think this patch is fixing that
problem; it's just
How about this fix on regression test of sepgsql?
It disables to launch regression test together with other modules,
and adds its own build target "sepgsql-installcheck" that launches
chkselinuxenv script then pg_regress command as currently we
are doing.
It allows users to launch regression test
On Mon, Sep 26, 2011 at 11:03 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Sep 26, 2011 at 10:04 AM, Tom Lane wrote:
>>> Another possibility is to remove the Makefile's knowledge of how to run
>>> the tests, and change chkselinuxenv into something that both verifies
>>> the environment a
2011/9/26 Tom Lane :
> Robert Haas writes:
>> On Mon, Sep 26, 2011 at 10:04 AM, Tom Lane wrote:
>>> Another possibility is to remove the Makefile's knowledge of how to run
>>> the tests, and change chkselinuxenv into something that both verifies
>>> the environment and then launches the tests.
>
Robert Haas writes:
> On Mon, Sep 26, 2011 at 10:04 AM, Tom Lane wrote:
>> Another possibility is to remove the Makefile's knowledge of how to run
>> the tests, and change chkselinuxenv into something that both verifies
>> the environment and then launches the tests.
> That's not a bad fix, eith
On Mon, Sep 26, 2011 at 10:04 AM, Tom Lane wrote:
> Peter Eisentraut writes:
>> On sön, 2011-09-25 at 23:49 -0400, Robert Haas wrote:
>>> In fact, I've been wondering if we ought to go a step further and not
>>> recurse into the sepgsql directory for *any* of the targets. Then we
>>> could get r
Peter Eisentraut writes:
> On sön, 2011-09-25 at 23:49 -0400, Robert Haas wrote:
>> In fact, I've been wondering if we ought to go a step further and not
>> recurse into the sepgsql directory for *any* of the targets. Then we
>> could get rid of the associated configure option, which no longer
>
On sön, 2011-09-25 at 23:49 -0400, Robert Haas wrote:
> In fact, I've been wondering if we ought to go a step further and not
> recurse into the sepgsql directory for *any* of the targets. Then we
> could get rid of the associated configure option, which no longer
> serves any other purpose, and j
2011/9/26 Tom Lane :
> As a stopgap, what about removing sepgsql from the list of contrib
> modules tested by "make -C contrib check"? (I haven't looked at
> exactly how ugly it might be to do that, nor whether we'd have to also
> disable installcheck from recursing to sepgsql.)
>
Is it unavailabl
On Mon, Sep 26, 2011 at 12:06 AM, Tom Lane wrote:
>> Then we
>> could get rid of the associated configure option, which no longer
>> serves any other purpose, and just say that if you want to build (or
>> regression-test) sepgsql, well, you gotta go to that directory and do
>> it by hand.
>
> The
Robert Haas writes:
> On Sun, Sep 25, 2011 at 9:07 PM, Tom Lane wrote:
>> As a stopgap, what about removing sepgsql from the list of contrib
>> modules tested by "make -C contrib check"?
> +1.
> In fact, I've been wondering if we ought to go a step further and not
> recurse into the sepgsql dir
On Sun, Sep 25, 2011 at 9:07 PM, Tom Lane wrote:
> As a stopgap, what about removing sepgsql from the list of contrib
> modules tested by "make -C contrib check"?
+1.
In fact, I've been wondering if we ought to go a step further and not
recurse into the sepgsql directory for *any* of the targets
So I thought it would be a good idea to enable contrib/sepgsql in the
Fedora build of 9.1. This soon crashed and burned, though, because
(1) if you build sepgsql, there is no way to omit the sepgsql regression
tests, other than by not regression-testing contrib at all. I didn't
see that as a ste
19 matches
Mail list logo
