Re: [HACKERS] Testlib.pm vs msys

On 07/26/2017 11:12 AM, Tom Lane wrote: > Andrew Dunstan writes: > >>> I still find this pretty ugly :-(. >> I'm open to alternative suggestions. But I don't want to spend a heck of >> a lot of time on this. > Well, let's at least do the temp files a little more

Re: [HACKERS] Testlib.pm vs msys

Andrew Dunstan writes: > On 07/26/2017 09:33 AM, Tom Lane wrote: >> It might be interesting to look into its copy of IPC::Run and see if >> the wait technology is different from later versions. > It's using 0.94 just like my Linux box. Oh well, I hoped maybe we

Re: [HACKERS] Testlib.pm vs msys

On 07/26/2017 09:33 AM, Tom Lane wrote: > Andrew Dunstan writes: > >> The latter fact makes me >> theorize that the problem arises from the fairly ancient perl that Msys >> provides, and which we need to use to run prove so the TAP tests >> understand the

Re: [HACKERS] Testlib.pm vs msys

Andrew Dunstan writes: > This made no difference. And I'm not really surprised, since the test is > not hanging when run from an MSVC build. Oh well. > The latter fact makes me > theorize that the problem arises from the fairly ancient perl that Msys > provides,

Re: [HACKERS] Testlib.pm vs msys

On 07/25/2017 02:45 PM, Andrew Dunstan wrote: >> Anyway, if we believe that it broke with f13ea95f9, hen it's plausible >> that CMD.EXE has been sharing pg_ctl's stdout/stderr all along, and we >> just had not noticed before. Could you check what happens if we >> change the bInheritHandles

Re: [HACKERS] Testlib.pm vs msys

On 07/25/2017 01:41 PM, Tom Lane wrote: > Andrew Dunstan writes: >> On 07/25/2017 11:25 AM, Tom Lane wrote: >>> Oh. So when was the last time it worked? And why do the buildfarm >>> archives contain apparently-successful log_stage entries for pg_ctl-check >>>

Re: [HACKERS] Testlib.pm vs msys

Andrew Dunstan writes: > On 07/25/2017 11:25 AM, Tom Lane wrote: >> Oh. So when was the last time it worked? And why do the buildfarm >> archives contain apparently-successful log_stage entries for pg_ctl-check >> on jacana, up through yesterday when I looked? >

Re: [HACKERS] Testlib.pm vs msys

On 07/25/2017 11:25 AM, Tom Lane wrote: > Andrew Dunstan writes: >> On 07/25/2017 11:11 AM, Tom Lane wrote: >>> What I'm on about is that jacana still succeeds entirely, more than half >>> the time. If this is a handle-duplication problem, how could it ever >>>

Re: [HACKERS] Testlib.pm vs msys

Andrew Dunstan writes: > On 07/25/2017 11:11 AM, Tom Lane wrote: >> What I'm on about is that jacana still succeeds entirely, more than half >> the time. If this is a handle-duplication problem, how could it ever >> succeed? > No, it hangs 100% of the time. The

Re: [HACKERS] Testlib.pm vs msys

On 07/25/2017 11:11 AM, Tom Lane wrote: > Andrew Dunstan writes: >> On 07/24/2017 09:33 PM, Tom Lane wrote: >>> Seems like the TAP test should fail every time, if this is a full >>> description. But maybe it's part of the answer, so it seems worth >>>

Re: [HACKERS] Testlib.pm vs msys

Andrew Dunstan writes: > On 07/24/2017 09:33 PM, Tom Lane wrote: >> Seems like the TAP test should fail every time, if this is a full >> description. But maybe it's part of the answer, so it seems worth >> experimenting in this direction. > The test that hangs is

Re: [HACKERS] Testlib.pm vs msys

On 07/24/2017 09:33 PM, Tom Lane wrote: > > [good theory about why pg_ctl hangs in TAP test] > > Now, this theory still has a Mack-truck-sized hole in it, which is > if that's the failure mechanism then why isn't it 100% effective? > Seems like the TAP test should fail every time, if this is a

Re: [HACKERS] Testlib.pm vs msys

I wrote: > Andrew Dunstan writes: >> The problem is command_like's use of redirection to strings. Why this >> should be a problem for this particular use is a matter of speculation. > I looked at jacana's two recent pg_ctlCheck failures, and they both > seem to

Re: [HACKERS] Testlib.pm vs msys

Andrew Dunstan writes: > It turns out I was wrong about the problem jacana has been having with > the pg_ctl tests hanging. The problem was not the use of select as a > timeout mechanism, although I think the change to using > Time::Hires::usleep() is correct and

[HACKERS] Testlib.pm vs msys

It turns out I was wrong about the problem jacana has been having with the pg_ctl tests hanging. The problem was not the use of select as a timeout mechanism, although I think the change to using Time::Hires::usleep() is correct and shouldn't be reverted. The problem is command_like's use of