Thread: Re: Cygwin test for current libpq sources?

Tom,

On Fri, Aug 03, 2001 at 06:16:28PM -0400, Tom Lane wrote:
>   I've just finished (I think) cleanup after the recent libpq patches to
> make it work better on Win32.  It is alleged that nonblocking mode works
> now on Win32.  I am wondering if things are working or broken on Cygwin,
> however.  When you get some time, would you pull CVS tip and try it out?

I just built the latest PostgreSQL CVS and ran it against essentially
the latest Cygwin CVS.  make check failed with many connection refused
false positives.  Previously, I would only get these occasionally.  Recall
that Windows NT 4.0 Workstation and 2000 Professional only have a backlog
size of 5.  Can the above mentioned changes be the cause of the increased
connection refused failures?

Additionally, I had (test) misc failures, but I believe that is due to the
other failures?  Is that assessment correct?

Since the parallel schedule was failing, I decided to try the serial one.
With the serial schedule, all tests passed except for random.  Normally,
I wouldn't worry, but random failed every time I ran either version of
the regression test except for once.  Does this indicate a problem?

So, I think that Cygwin PostgreSQL is OK, but I'm not completely sure...

Is there anything else that you would like me to try?

Thanks,
Jason

Tom,

I forgot to mention in my last email that I could not compile the
latest PostgreSQL CVS under Cygwin without the attached (hacky) patch.
Does PostgreSQL CVS (i.e., libpq++) compile cleanly with gcc 2.95.2 under
other platforms?  If so, then I will try to pursue this issue properly.

Thanks,
Jason

Jason Tishler <jason@tishler.net> writes:
> I just built the latest PostgreSQL CVS and ran it against essentially
> the latest Cygwin CVS.  make check failed with many connection refused
> false positives.  Previously, I would only get these occasionally.  Recall
> that Windows NT 4.0 Workstation and 2000 Professional only have a backlog
> size of 5.  Can the above mentioned changes be the cause of the increased
> connection refused failures?

Hmm.  I do not think so.  The worrisome possibility is that our earlier
changes that make the postmaster fork() first and authenticate later
might be hurting performance, rather than helping it, at least on
Windows.  But it's difficult to see why.  Successful connections must
do a fork() sooner or later, so how could there be any net loss of
performance?

What authentication protocol are you using in this test?

> Additionally, I had (test) misc failures, but I believe that is due to the
> other failures?  Is that assessment correct?

Quite a few of the tests are dependent on data inserted by earlier
tests, so I wouldn't worry too much about failures occurring after the
first connection-refused.  You could look at the detail diffs and verify
that they look like missing data or missing tables.

> With the serial schedule, all tests passed except for random.  Normally,
> I wouldn't worry, but random failed every time I ran either version of
> the regression test except for once.  Does this indicate a problem?

I doubt it.

            regards, tom lane

Tom,

On Thu, Aug 16, 2001 at 07:23:16PM -0400, Tom Lane wrote:
> Jason Tishler <jason@tishler.net> writes:
> > Can the above mentioned changes be the cause of the increased
> > connection refused failures?
>
> Hmm.  I do not think so.  The worrisome possibility is that our earlier
> changes that make the postmaster fork() first and authenticate later
> might be hurting performance, rather than helping it, at least on
> Windows.  But it's difficult to see why.  Successful connections must
> do a fork() sooner or later, so how could there be any net loss of
> performance?

From the PostgreSQL side, I don't see how either.  But, maybe the latest
Cygwin is slower which is making the backend slower?  Another possibility,
is that the Cygwin DLL that I'm using has vfork turned on, so maybe the
tests (i.e., the frontends) are being started faster than before?

I suggest that Terry Carlin rerun his benchmark suite on PostgreSQL
CVS running under Cygwin's most recent snapshot to see if he is getting
connection refused failures too.

> What authentication protocol are you using in this test?

I presume nothing (i.e., trust) or whatever is the default.  Remember,
I'm just doing a "make check".

> > Additionally, I had (test) misc failures, but I believe that is due to the
> > other failures?  Is that assessment correct?
>
> Quite a few of the tests are dependent on data inserted by earlier
> tests, so I wouldn't worry too much about failures occurring after the
> first connection-refused.  You could look at the detail diffs and verify
> that they look like missing data or missing tables.

The above describes what I'm seeing in the diffs so I will ignore the
misc failures.

Thanks,
Jason