Hello,
At Fri, 30 Sep 2016 13:11:21 +0900, Masahiko Sawada <sawada.mshk@gmail.com> wrote in
<CAD21AoC1Ztdbp1v-qEnRn=RxaC0M6ZaTb4Cj8RyG+Dvs4MAHSw@mail.gmail.com>
> On Fri, Sep 30, 2016 at 7:08 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Alvaro Herrera <alvherre@2ndquadrant.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.
I was careless about that..
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center