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 по дате отправления: