From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Jan Wieck <wieck(at)debis(dot)com>, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] Parallel regress tests (was Re: FOREIGN KEY and shift/reduce) |
Date: | 1999-12-07 18:21:07 |
Message-ID: | 24116.944590867@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <e99re41(at)DoCS(dot)UU(dot)SE> writes:
>> Peter, in your slicing and dicing of psql, did you end up with anything
>> that might make this a feasible approach?
> 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...
Another possible approach is to accept that a parallel multi-backend
test lashup *doesn't* have to run on every single system that Postgres
runs on, if we keep it separate from the standard regress tests.
For example, it's not much work to build a parallel test driver in Perl
(I have done it), and I think that an auxiliary test package that
requires Perl would be acceptable.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Kyle Bateman | 1999-12-07 18:36:14 | Re: [HACKERS] Raising funds for PostgreSQL |
Previous Message | Peter Eisentraut | 1999-12-07 18:09:50 | Re: [HACKERS] Parallel regress tests (was Re: FOREIGN KEY and shift/reduce) |