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) #
