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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] Parallel regress tests (was Re: FOREIGN KEY and shift/reduce)
Дата
Msg-id 24116.944590867@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] Parallel regress tests (was Re: FOREIGN KEY and shift/reduce)  (Peter Eisentraut <e99re41@DoCS.UU.SE>)
Ответы Re: [HACKERS] Parallel regress tests (was Re: FOREIGN KEY and shift/reduce)  (Vince Vielhaber <vev@michvhf.com>)
Re: [HACKERS] Parallel regress tests (was Re: FOREIGN KEY and shift/reduce)  (Peter Eisentraut <e99re41@DoCS.UU.SE>)
Список pgsql-hackers
Peter Eisentraut <e99re41@DoCS.UU.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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: [HACKERS] Parallel regress tests (was Re: FOREIGN KEY and shift/reduce)
Следующее
От: Kyle Bateman
Дата:
Сообщение: Re: [HACKERS] Raising funds for PostgreSQL