Обсуждение: pgsql: Reduce risk of accidentally running temp-install regression tests

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)

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

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

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!