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

From Peter Eisentraut
Subject Re: [HACKERS] Parallel regress tests (was Re: FOREIGN KEY and
Date
Msg-id Pine.GSO.4.02A.9912072138190.3057-100000@Panter.DoCS.UU.SE
Whole thread Raw
In response to Re: [HACKERS] Parallel regress tests (was Re: FOREIGN KEY and  (wieck@debis.com (Jan Wieck))
Responses Re: [HACKERS] Parallel regress tests (was Re: FOREIGN KEY and
List pgsql-hackers
On Tue, 7 Dec 1999, Jan Wieck wrote:

> > 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.

Well, we're testing and not benchmarking...

>     code should do it. Only  that  I  would  like  to  use  pipes
>     to/from  psql  instead  of  dealing with libpq and formatting
>     myself.

If you like, the print routines in psql are competely isolated from the
rest of the code and you can just #include and use them.

>     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.

I'm going to go an a flush hunt...

-- 
Peter Eisentraut                  Sernanders vaeg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden




pgsql-hackers by date:

Previous
From: Kyle Bateman
Date:
Subject: Re: [HACKERS] Raising funds for PostgreSQL
Next
From: Keith Parks
Date:
Subject: Table aliases in delete statements?