Re: [HACKERS] Parallel regress tests (was Re: FOREIGN KEY and - Mailing list pgsql-hackers

From wieck@debis.com (Jan Wieck)
Subject Re: [HACKERS] Parallel regress tests (was Re: FOREIGN KEY and
Date
Msg-id m11vPpT-0003kGC@orion.SAPserv.Hamburg.dsh.de
Whole thread Raw
In response to Re: [HACKERS] Parallel regress tests (was Re: FOREIGN KEY and shift/reduce)  (Peter Eisentraut <e99re41@DoCS.UU.SE>)
Responses Re: [HACKERS] Parallel regress tests (was Re: FOREIGN KEY and
List pgsql-hackers
Peter Eisentraut wrote:

> On Tue, 7 Dec 1999, Tom Lane wrote:
>
> > I assume that the \! command won't continue until the subjob exits?
> > If so, this doesn't give us any way to verify that query A will wait for
> > query B to finish ... at least not without locking up the test...
>
> I'm kind of losing you here. You want parallel execution *and* a
> predefined order of execution? In my (limited) book, those contradict each
> other a little bit. If it helps you can also do this:
> \! psql -f 'second-script' >& output &
> and the thus invoked script will happily continue executing even after you
> quit the first psql.

    Yes,  we  mean  controlled order of execution across multiple
    backends. And a script invoked in background, like the above,
    doesn't  do  the trick - and BTW we already have that kind of
    testing.

> I guess you could also do some simple synchronization things, like have
> the second psql wait on a file to spring into existence:
> /* second-script */
> \! while [ ! -f /tmp/lock.file ]; do ;; done
> \! rm /tmp/lock.file
>
> Kind of like a simple semaphore. Isn't that what you are getting at?

    Kind of, but wasting CPU while waiting. OTOH,  some  sleep(1)
    inside the loop would slow down to a certain degree.

    As  usual,  Tom and I had similar ideas. A little amount of C
    code should do it. Only  that  I  would  like  to  use  pipes
    to/from  psql  instead  of  dealing with libpq and formatting
    myself.

    One problem I noticed so  far  is,  that  the  new  psql  (in
    contrast  to  the  v6.5  one)  doesn't flush it's output when
    doing it to a pipe.  To control  that  one  backend  finished
    execution  of  a  query,  I thought to send a special comment
    line and wait for it to be echoed back. This would only  work
    if psql flushes.

    Peter,  could  you  please  add  some  switch  to  psql  that
    activates an fflush() whenever psql would like to  read  more
    input  commands.  In  the  meantime  I can start to write the
    driver using the v6.5 psql.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#========================================= wieck@debis.com (Jan Wieck) #

pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: [HACKERS] Parallel regress tests (was Re: FOREIGN KEY and shift/reduce)
Next
From: Lamar Owen
Date:
Subject: Re: Postgresql in win9x