Skip site navigation (1) Skip section navigation (2)

regresssion script hole

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: regresssion script hole
Date: 2006-06-18 21:30:55
Message-ID: 4495C60F.9090509@dunslane.net (view raw, whole thread or download thread mbox)
Thread:
Lists: pgsql-hackers
While investigating some problems with buildfarm member spoonbill I came 
across this piece of code in pg_regress.sh, which seems less than robust:


    # Wait till postmaster is able to accept connections (normally only
    # a second or so, but Cygwin is reportedly *much* slower).  Don't
    # wait forever, however.
    i=0
    max=60
    until "$bindir/psql" -X $psql_options postgres </dev/null 2>/dev/null
    do
        i=`expr $i + 1`
        if [ $i -ge $max ]
        then
            break
        fi
        if kill -0 $postmaster_pid >/dev/null 2>&1
        then
            : still starting up
        else
            break
        fi
        sleep 1
    done

    if kill -0 $postmaster_pid >/dev/null 2>&1
    then
        echo "running on port $PGPORT with pid $postmaster_pid"
    else
        echo
        echo "$me: postmaster did not start"
        echo "Examine $LOGDIR/postmaster.log for the reason."
        echo
        (exit 2); exit
    fi

The problem is that if the postmaster takes more than 60 seconds to 
start listening (as is apparently happening on spoonbill - don't yet 
know why) this code falls through.

I'm inclined to run the psql test one more time to make sure we can 
actually connect, and if not then fail at this point. I wouldn't bother 
but it did confuse the heck out of both Stefan and me when createlang 
failed.

Thoughts?

cheers

andrew

Responses

pgsql-hackers by date

Next:From: paolo romanoDate: 2006-06-18 21:35:25
Subject: Re: MultiXacts & WAL
Previous:From: Tom LaneDate: 2006-06-18 21:26:16
Subject: Re: Rethinking stats communication mechanisms

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group