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)
Re: [HACKERS] Parallel regress tests (was Re: FOREIGN KEY and shift/reduce) |
Список | 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 по дате отправления: