Re: Is this a bug in pg_current_logfile() on Windows?

From: Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Thomas Kellerer <shammat(at)gmx(dot)net>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Is this a bug in pg_current_logfile() on Windows?
Date: 2020-07-09 13:43:53
Message-ID: fcf4b905-8aff-2c65-ae4c-ec28a9a02370@2ndQuadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers


On 7/8/20 10:40 PM, Tom Lane wrote:
> I wrote:
>> Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> writes:
>>> Seems reasonable. If we rip it out completely we'll have to find all the
>>> places it breaks and fix them. And we'll almost certainly get new
>>> breakage. If it's hiding a real bug we'll have to do that, but I'd be
>>> reluctant unless there's actual proof.
>> Hard to tell. What I propose to do right now is change the \r filters
>> as shown above, and see if the test I added in 004_logrotate.pl starts
>> to show failures on Windows. If it does, and no other place does,
>> I'm willing to be satisfied with that. If we see *other* failures then
>> that'd prove that the problem is real, no?
> 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.

Attached for reference is the IPC::Run package I usually use on Windows.

>
> One thing I noticed while making 91bdf499b is that some of these
> substitutions are conditioned on "if $TestLib::windows_os" while others
> are conditioned on "if $Config{osname} eq 'msys'". What is the reason
> for this difference? Is it possible that we only really need to do it
> in the latter case?
>
>

In general I make the condition for such hacks as restrictive as
possible. I don't guarantee that I have been perfectly consistent about
that, though.

cheers

andrew

--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Attachment Content-Type Size
IPC-Run-Win-0.94.tgz application/x-compressed-tar 64.0 KB

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Laurent FAILLIE 2020-07-09 13:53:46 Clustering solution ?
Previous Message Brajendra Pratap Singh 2020-07-09 08:58:03 Re: Kerberos-Postgresql implementation for user authentication

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2020-07-09 13:51:51 Re: Stale external URL in doc?
Previous Message Amit Kapila 2020-07-09 13:24:47 Re: replication_origin and replication_origin_lsn usage on subscriber