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 safely.
> Maybe like this?
>
>
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 could update that.
>> I still fin
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 environment's virtualized file paths.
>
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, and which we need to use to run p
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 param
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
>>> on jacana, up through yesterday wh
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?
> There was a buildfarm bug, since
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
>>> succeed?
>> No, it hangs 100% of
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 only time you see a result at all
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
>>> experimenting in this direction.
>> The tes
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 the only case where we call pg_c
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 fu
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 have failed on this:
> command_like
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 shouldn't be reverted.
> The prob
14 matches
Mail list logo
