Andrew Dunstan wrote:

>> As far as the test failure, maybe we are just not allowing enough time
>> for the stats collector to run? The thing sits there for 2 sec, which
>> theoretically is plenty, but it's a busy-wait loop and if the Cygwin
>> scheduler is not aggressive about taking away timeslices then maybe
>> the stats processes don't get to run. Try doing the test script by
>> hand, with just a manual delay instead of the sleep function, and see
>> if it passes.
>>
>>
>>
>>
>
> Yes, when I do that it works. But even when I increase the interval to
> 30 secs the regression script fails. I tried to use a sleep function
> that didn't do a busy-wait loop, but plperl seems to segfault on this
> platform :-( What fun.
>
>

Further data point - the expected result appears when I set the sleep
interval at 1 minute, but not at 40 secs. That does indicate that the
stats collector is actually running and doing its job (kinda).

cheers

andrew

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

Andrew Dunstan <andrew@dunslane.net> writes:
> Further data point - the expected result appears when I set the sleep
> interval at 1 minute, but not at 40 secs. That does indicate that the
> stats collector is actually running and doing its job (kinda).

Hmm ... maybe the intentional sleep in the stats collector is delaying
much longer than it is supposed to?

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

> Tom Lane wrote:
>>Andrew Dunstan <andrew@dunslane.net> writes:
>>
>>>What has changed in the last 3 weeks is that I refreshed my Cygwin
>>> installation, I think when I was wrestling with the NLS thing. If
>>> nothing in postgres has changed in this area I assume that platform
>>> changes account for the regression.
>>
>>Sounds that way to me too, but it's disturbing. One would say they
>> broke their scheduler :-(. Possibly you should try to stir up some
>> interest among the Cygwin hackers in looking into this.
>>
>
> I'd like somebody else to report the same phenomenon first. Reini?

Why plperl is broken I cannot say yet.

I still have the same general IPC permission problem since about beta3.
Only very few cygwin hackers have this also.
I only got confirmation that the problem is in postgresql, not in cygwin.
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/



---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

Reini Urban said:
>> Tom Lane wrote:
>>>Andrew Dunstan <andrew@dunslane.net> writes:
>>>
>>>>What has changed in the last 3 weeks is that I refreshed my Cygwin
>>>> installation, I think when I was wrestling with the NLS thing. If
>>>> nothing in postgres has changed in this area I assume that platform
>>>> changes account for the regression.
>>>
>>>Sounds that way to me too, but it's disturbing. One would say they
>>> broke their scheduler :-(. Possibly you should try to stir up some
>>> interest among the Cygwin hackers in looking into this.
>>>
>>
>> I'd like somebody else to report the same phenomenon first. Reini?
>
> Why plperl is broken I cannot say yet.
>
> I still have the same general IPC permission problem since about beta3.
> Only very few cygwin hackers have this also.
> I only got confirmation that the problem is in postgresql, not in
> cygwin.

Hmm. Well, JimB got the same result yesterday that I have been seeing (the
stats regression test failure), so I consider that sufficient confoirmation.

I'm not quite sure what question I should be asking of the Cygwin people.
Tom, Can you suggest something?

I'll look at the plperl thing. That has also prompted me to add a buildfarm
feature request to test perl, python and tcl if they are configured in.

cheers

andrew



---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

"Andrew Dunstan" <andrew@dunslane.net> writes:
> I'm not quite sure what question I should be asking of the Cygwin people.
> Tom, Can you suggest something?

It sounds to me like the problem is that the backend executing the test
script is in a tight loop (due to the half-baked implementation of sleep())
and for some reason this prevents the stats processes from running ---
for a far longer period than it by rights ought to. Ask about recent
changes in process scheduling policy. (I suppose that actually it's
Windows doing the scheduling, but what we want to know about is cygwin
changes that might have affected Windows scheduling parameters.)

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Tom Lane wrote:

>"Andrew Dunstan" <andrew@dunslane.net> writes:
>
>
>>I'm not quite sure what question I should be asking of the Cygwin people.
>>Tom, Can you suggest something?
>>
>>
>
>It sounds to me like the problem is that the backend executing the test
>script is in a tight loop (due to the half-baked implementation of sleep())
>and for some reason this prevents the stats processes from running ---
>for a far longer period than it by rights ought to. Ask about recent
>changes in process scheduling policy. (I suppose that actually it's
>Windows doing the scheduling, but what we want to know about is cygwin
>changes that might have affected Windows scheduling parameters.)
>
>

The only answer so far received says:

Sounds to me like yet another case of
http://cygwin.com/ml/cygwin/2005-03/msg00730.html

cheers

andrew



---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

Andrew,

I can confirm that the latest cygwin snapshot (cygwin1-20050328.dll) corrects the stats regression failure.

Jim



---------- Original Message -----------
From: Andrew Dunstan <andrew@dunslane.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: rurban@x-ray.at, pgsql-hackers@postgresql.org
Sent: Wed, 30 Mar 2005 07:21:50 -0500
Subject: Re: [HACKERS] minor windows & cygwin regression failures on stable

> Tom Lane wrote:
>
> >"Andrew Dunstan" <andrew@dunslane.net> writes:
> >
> >
> >>I'm not quite sure what question I should be asking of the Cygwin people.
> >>Tom, Can you suggest something?
> >>
> >>
> >
> >It sounds to me like the problem is that the backend executing the test
> >script is in a tight loop (due to the half-baked implementation of sleep())
> >and for some reason this prevents the stats processes from running ---
> >for a far longer period than it by rights ought to. Ask about recent
> >changes in process scheduling policy. (I suppose that actually it's
> >Windows doing the scheduling, but what we want to know about is cygwin
> >changes that might have affected Windows scheduling parameters.)
> >
> >
>
> The only answer so far received says:
>
> Sounds to me like yet another case of
> http://cygwin.com/ml/cygwin/2005-03/msg00730.html
>
> cheers
>
> andrew
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
------- End of Original Message -------


---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

Jim Buttafuoco wrote:

>I can confirm that the latest cygwin snapshot (cygwin1-20050328.dll) corrects the stats regression failure.
>
>
>

Yes, it does for me too. Thanks

andrew

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend