Re: [HACKERS] Parallel regress tests (was Re: FOREIGN KEY and shift/reduce)

On Tue, 7 Dec 1999, Tom Lane wrote:

> > Um, you could call another psql from within psql, like so:
>
> > /* psql script */
> > create this
> > select that
> > \! psql -f 'second-script'
> > select more
>
> > That satisfies the requirement of two separate sessions and a predefined
> > order.
>
> 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.

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?

In the overall view of things it almost seems like these kind of tests
need a human eye supervising them, because how do really determine "query
A waits for query B to finish" otherwise?

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