Re: "make check" improvement for cygwin
От | Andrew Dunstan |
---|---|
Тема | Re: "make check" improvement for cygwin |
Дата | |
Msg-id | 001101c39cf1$b5f17ee0$6401a8c0@DUNSLANE обсуждение исходный текст |
Ответ на | "make check" improvement for cygwin ("Andrew Dunstan" <andrew@dunslane.net>) |
Ответы |
Re: "make check" improvement for cygwin
|
Список | pgsql-patches |
----- Original Message ----- From: "Tom Lane" <tgl@sss.pgh.pa.us> To: "Andrew Dunstan" <andrew@dunslane.net> Cc: "PG Patches" <pgsql-patches@postgresql.org> Sent: Monday, October 27, 2003 7:41 PM Subject: Re: [PATCHES] "make check" improvement for cygwin > "Andrew Dunstan" <andrew@dunslane.net> writes: > > The attached patch limits parallelism for "make check" on cygwin to 10 - me= > > aning that at least on my installation "make check" actually succeeds at la= > > st. > > If we're going to do something like that, I'd rather see it exposed as a > more general "at most N connections" knob, where the user could choose > N. There are plenty of other scenarios where such a restriction could > be useful --- for instance, "make check" runs up against > max-processes-per-user limits on a number of platforms. > > I would also rather that the user be forced to supply that number, to > make certain he realizes that he's got a very low number-of-connections > resource limit. Sweeping such problems under the rug is exactly what > "make check" should not do. > Sure - I was just sharing what I did to get things working, as I have seen reports on this from a number of people. I should be able to generalise it fairly easily. Something like this? make MAX_CONNECTIONS=10 check Maybe in the case of cygwin, where it is almost bound to fail without such restrictions, we could put out a warning if it isn't used. cheers andrew
В списке pgsql-patches по дате отправления: