Thread: pgsql: Reduce risk of accidentally running temp-install regression tests
pgsql: Reduce risk of accidentally running temp-install regression tests
From
petere@postgresql.org (Peter Eisentraut)
Date:
Log Message:
-----------
Reduce risk of accidentally running temp-install regression tests against
a mismatching installation. Pick a default port number calculated from the
version number, and try a few times with other numbers if that one doesn't
work. Check if we can connect to the port before starting our own postmaster,
to detect some other server already running there. To simplify the code,
drop --temp-port option and use --port for both temp-install and pre-installed
case.
Modified Files:
--------------
pgsql/src/test/regress:
GNUmakefile (r1.75 -> r1.76)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/GNUmakefile?r1=1.75&r2=1.76)
pg_regress.c (r1.53 -> r1.54)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/pg_regress.c?r1=1.53&r2=1.54)
Re: pgsql: Reduce risk of accidentally running temp-install regression tests
From
Andrew Dunstan
Date:
Peter Eisentraut wrote: > Log Message: > ----------- > Reduce risk of accidentally running temp-install regression tests against > a mismatching installation. Pick a default port number calculated from the > version number, and try a few times with other numbers if that one doesn't > work. Check if we can connect to the port before starting our own postmaster, > to detect some other server already running there. To simplify the code, > drop --temp-port option and use --port for both temp-install and pre-installed > case. > > Modified Files: > -------------- > pgsql/src/test/regress: > GNUmakefile (r1.75 -> r1.76) > (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/GNUmakefile?r1=1.75&r2=1.76) > pg_regress.c (r1.53 -> r1.54) > (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/pg_regress.c?r1=1.53&r2=1.54) > > This has apparently broken the ECPG tests - see buildfarm where multiple members are red. cheers andrew
Andrew Dunstan <andrew@dunslane.net> writes:
> Peter Eisentraut wrote:
>> Log Message:
>> -----------
>> Reduce risk of accidentally running temp-install regression tests against
>> a mismatching installation.
> This has apparently broken the ECPG tests - see buildfarm where multiple
> members are red.
Yes, ecpg is still using the temp-port parameter that Peter removed :-(.
I have temporarily turned things green again (I think) by making ecpg
use --port instead, which is the new spelling of --temp-port. However,
this is not really satisfactory because it negates the whole point of
Peter's patch, namely to have a less brittle way of selecting the
temp port. But it looks like the temp port number is actually wired
into some of the ecpg tests' expected results, and so getting rid of it
is not as easy as one could wish.
Michael, could you look at removing that dependency so we can let
pg_regress.c select the port number as it wishes? If it's not practical
to suppress the port number in the regression test output, maybe things
could be changed so that pg_regress.c itself substitutes in the port
number it's chosen.
regards, tom lane
Re: pgsql: Reduce risk of accidentally running temp-install regression tests
From
Michael Meskes
Date:
On Fri, Nov 28, 2008 at 06:54:15PM -0500, Tom Lane wrote: > temp port. But it looks like the temp port number is actually wired > into some of the ecpg tests' expected results, and so getting rid of it > is not as easy as one could wish. Should only one test, that some installations do not even run, but still, yes, it makes things more difficult. > Michael, could you look at removing that dependency so we can let > pg_regress.c select the port number as it wishes? If it's not practical > to suppress the port number in the regression test output, maybe things > could be changed so that pg_regress.c itself substitutes in the port > number it's chosen. Suppressing the output defies the purpose for this one test, namely to check different ways to connect. If pg_regress is able do the job of two sed calls in can easily substitute the port number itself. I'm not sure if this is worth the hassle, or whether we just remove these parts of the regression test. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!
Michael Meskes <meskes@postgresql.org> writes:
> Suppressing the output defies the purpose for this one test, namely to check
> different ways to connect. If pg_regress is able do the job of two sed calls in
> can easily substitute the port number itself. I'm not sure if this is worth the
> hassle, or whether we just remove these parts of the regression test.
Well, pg_regress already does some comparable things for the core
regression tests, see convert_sourcefiles_in(). Whether it's worth
the hassle to have a test for this case isn't clear to me. It doesn't
seem like something particularly likely to break.
regards, tom lane
Re: pgsql: Reduce risk of accidentally running temp-install regression tests
From
Michael Meskes
Date:
On Sun, Nov 30, 2008 at 01:29:02PM -0500, Tom Lane wrote: > Well, pg_regress already does some comparable things for the core > regression tests, see convert_sourcefiles_in(). Whether it's worth > the hassle to have a test for this case isn't clear to me. It doesn't > seem like something particularly likely to break. Exactly. That's why I just removed this stuff. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!