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.)
regards, tom lane