On 7/9/20 10:44 AM, Tom Lane wrote:
> Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
>> On 7/8/20 10:40 PM, Tom Lane wrote:
>>> So I did that, and the first report is from bowerbird and it's still
>>> green. Unless I'm completely misinterpreting what's happening (always
>>> a possibility), that means we're still managing to remove "data"
>>> occurrences of \r.
>>> The most likely theory about that, I think, is that IPC::Run::run already
>>> translated any \r\n occurrences in the psql command's output to plain \n.
>>> Then, the \r generated by pg_current_logfile() would butt up against the
>>> line-ending \n, allowing the "fix" in sub psql to remove valid data.
>> It's possible. I do see some mangling of that kind in IPC::Run's
>> Win32IO.pm and Win32Pump.pm.
> The plot thickens: as of this morning, fairywren and jacana are showing
> the failure I expected, while drongo and bowerbird are not. (Our other
> Windows animals are not running the TAP tests, so they're no help here.)
>
> It's not hard to believe that the latter two are using a different libc
> implementation, but how would that affect the behavior of the TAP
> infrastructure? Are they also using different Perls? (By hypothesis,
> the pg_current_logfile bug exists across all Windows builds, so we have
> to explain why the TAP tests only reveal it on some of these animals.)
>
>
They should use the same libc implementation (msvcrt.dll).
But the perls they are using are indeed different - msys animals have to
use msys' perl for TAP tests because native perl doesn't understand msys
file paths. Conversely, MSVC animals must use native perl (AS or
Strawberry) to run TAP tests. So jacana and fairywren, the two msys
animals, are doing what you expect5ed and drongo and bowerbird, the two
MSVC animals, are not.
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
