Re: Testing with concurrent sessions

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: Testing with concurrent sessions
Дата
Msg-id 4B460FFD.2070400@dunslane.net
обсуждение исходный текст
Ответ на Re: Testing with concurrent sessions  ("David E. Wheeler" <david@kineticode.com>)
Ответы Re: Testing with concurrent sessions  (Robert Haas <robertmhaas@gmail.com>)
Re: Testing with concurrent sessions  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Testing with concurrent sessions  ("Greg Sabino Mullane" <greg@turnstep.com>)
Список pgsql-hackers

David E. Wheeler wrote:
> On Jan 6, 2010, at 6:26 PM, Tom Lane wrote:
>
>   
>> We have not yet fully accepted the notion that you must have Perl to
>> build (and, in fact, I am right now trying to verify that you don't).
>> I don't think that requiring Perl to test is going to fly.
>>     
>
> I believe that the build farm already requires Perl, regardless of whether the PostgreSQL build itself requires it.
>
>
>   

Unless I am mistaken, Perl is required in any case to build from CVS, 
although not from a tarball.

DBI/DBD::pg is quite another issue, however. I have been deliberately 
very conservative about what modules to require for the buildfarm, and 
we have similarly (and I think wisely) been conservative about what 
modules to require for Perl programs in the build process.

Using DBI/DBD::Pg would raise another issue - what version of libpq 
would it be using? Not the one in the build being tested, that's for 
sure. If you really want to use Perl then either a Pure Perl DBI driver 
(which Greg has talked about) or a thin veneer over libpq such as we 
used to have in contrib seems a safer way to go.

cheers


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Testing with concurrent sessions
Следующее
От: Joachim Wieland
Дата:
Сообщение: Re: Hot Standy introduced problem with query cancel behavior