Re: [GENERAL] pg_upgrade from 9.5 to 9.6 fails with "invalid argument"

On Fri, Sep 30, 2016 at 1:26 PM, Kyotaro HORIGUCHI
<horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> wrote:
> Hello,
>
> At Fri, 30 Sep 2016 13:11:21 +0900, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote in <CAD21AoC1Ztdbp1v-qEnRn=RxaC0M6ZaTb4Cj8RyG+Dvs4MAHSw(at)mail(dot)gmail(dot)com>
>> On Fri, Sep 30, 2016 at 7:08 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> > Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
>> >> Tom Lane wrote:
>> >>> I wouldn't even put a lot of faith in the errno being meaningful,
>> >>> considering that it does close() calls before capturing the errno.
>> >
>> >> So we do close() in a bunch of places while closing shop, which calls
>> >> _close() on Windows; this function sets errno.
>> >
>> > But only on failure, no? The close()s usually shouldn't fail, and
>> > therefore shouldn't change errno, it's just that you can't trust that
>> > 100%.
>> >
>> > I think likely what's happening is that we're seeing a leftover value from
>> > some previous syscall that set GetLastError's result (and, presumably,
>> > wasn't fatal so far as pg_upgrade was concerned).
>> >
>>
>> It means that read() syscall could not read BLOCKSZ bytes because
>> probably _vm file is corrupted?
>>
>> > if ((src_fd = open(fromfile, O_RDONLY, 0)) < 0)
>>
>> It could be happen that read() syscall stopped to read at where it
>> reads bits representing '\n' characters (0x5c6e) because we don't open
>> file with O_BINARY flag?
>
> Windows behaves stupidly there. fread() and even() read converts
> '\r\n' into '\n' when text mode so every sequence of [0d 0a] in
> the reading bytes shortens the data length by 1 byte.
>

Ah, [0d 0a] is right.
After I manually added [0d 0a] into _vm file, I reproduced this bug on Windows.
I will post the patch.

Regards,

--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center