Joek,
On Thu, Aug 29, 2002 at 12:11:11PM +0200, joek hondius wrote:
> >On Tue, Aug 27, 2002 at 04:45:49PM +0200, joek hondius wrote:
> >> I could not find any pointer to this in the cygwin or postgresql
> >> docs about this. Jason Tishler noted this before in a review of
> >> why 'make test' (parallel) failed (one year ago).
> >
> >I don't recall the above. Please provide an URL.
>
> Somehow i could not find the original postings anymore (they where
> there 3 weeks ago),
They recently fell off the end of the PostgreSQL mailing list archives.
> but thanks to google's cache:
>
http://www.google.nl/search?q=cache:CXMBRFwDZUwC:postgresql.linux.cz/mhonarc/pgsql-ports/2001-03/msg00128.html+&hl=nl&ie=UTF-8
The above refers to a bug in libpq. See the following thread for the
details:
http://www.geocrawler.com/mail/thread.php3?subject=%5BPORTS%5D+Cygwin+PostgreSQL+Regression+Test+Problems+%28Revisited%29&list=104
Specifically, the following:
http://www.geocrawler.com/mail/msg.php3?msg_id=5455858&list=104
> >Are you referring to the following (from the README)?
> >
> > 1. make check can generate spurious regression test failures due to
> > overflowing the the listen() backlog queue which generates
> > connection refused errors. Note that make installcheck does not
> > have this problem since it runs all tests sequentially instead of in
> > large concurrent groups.
>
> But this is not a backlog problem.
Understood.
> Its seems to me to be a fork() to windows mapping problem. The
> WaitForObject() winAPI call is limited to 63. So postgreSQL really
> seems limited to 63 backends on cygwin. :(
Unfortunately, Cygwin has this limitation.
Nevertheless, the fork() issue is not why make check above failed. I
was just trying to clear this up for the archives.
Jason