Re: pgsql: Refactor all TAP test suites doing connection checks
От | Tom Lane |
---|---|
Тема | Re: pgsql: Refactor all TAP test suites doing connection checks |
Дата | |
Msg-id | 939270.1617673418@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pgsql: Refactor all TAP test suites doing connection checks (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-committers |
I wrote: > Well, since it's a race condition it's obviously going to be sensitive to > machine speed. I think that Perl version, or more likely version of > IPC::Run or a related module, may enter into it too. prairiedog has > gotten through the tests several times since yesterday without failing, > yet it's significantly slower than the other PPC Mac I was able to > consistently reproduce the problem on. I don't think those two have > the same vintage of Perl installation, though, so Perl version seems > like a likely explanation. Just for the archives' sake: prairiedog (passed 3 out of 3 tries): 450MHz PPC32 Perl 5.8.3 $ perl -MIPC::Run -e 'print $IPC::Run::VERSION ."\n";' 0.79 (file dates on the IPC::Run files are 2004) gaur (failed 1 out of 1 tries): 360MHz HPPA Perl 5.8.9 IPC::Run 0.94 (file dates 2014) my other PPC Mac (failed consistently, 10 out of 10): 1.33GHz PPC32 Perl 5.8.8 IPC::Run 20180523.0 Not sure what to make of that, though a regression in IPC::Run seems possible. It's also possible that buildfarm script (the first two) versus manual invocation (the last) is related somehow. regards, tom lane
В списке pgsql-committers по дате отправления: