Re: Cygwin PostgreSQL Regression Test Problems (Revisited)

Jason Tishler <Jason.Tishler@dothill.com> writes:
>> It seems clear that it's a good idea for fe-misc.c to check the
>> exceptfds bit as well as read/write ready --- I'm surprised we have not
>> seen problems associated with that on other platforms.  I think it
>> should check exceptfds all the time, regardless of whether we are
>> waiting to read or to write.

> I'm glad that you agree.  Please post to the list when the change is in
> CVS and I will test that this solves the Cygwin regression test (i.e.,
> psql) hangs.

Done as of yesterday; should be in this morning's snapshot.

> Actually, the blocking connect() change for Cygwin is obviated by the
> pqWait() fix.  So, I am now no longer recommending making the blocking
> connect() change for Cygwin.  Unless, you do so for other Unixes too.

I made both changes in the hope that the blocking connect change would
suppress your problem with connection-refused failures.  If it does not,
then we may as well reverse out the fe-connect.c change.  Let me know.

>> If we do both of those things, have we
>> resolved the issue on Cygwin, or is there still a problem?

> I'm wondering whether it makes sense to add a simple connection retry
> policy as suggested above by Hiroshi?

I do not think it is appropriate for libpq to do that.  For one thing,
where would you stop --- why exactly two tries?

> 2. Change the backlog parameter to listen() in src/backend/libpq/pqcomm.c
> to a number that will "ensure" that the parallel_schedule version of the
> regression test does not generate connection refused conditions.  Note
> that I'm not even sure this will really work on all (or any) platforms.

We already use SOMAXCONN which is supposed to be defined by the system
as the maximum allowed queue depth.  If Cygwin fails to define it, or
defines it as something less than it should be, then we might consider
installing a Cygwin-specific hack to redefine SOMAXCONN.  However
Hiroshi says later that he already tried this.  I'm inclined to think
that Cygwin simply has a problem with servicing concurrent connection
requests, perhaps even before the alleged SOMAXCONN value is reached.

            regards, tom lane