Hello, At Fri, 30 Sep 2016 13:11:21 +0900, Masahiko Sawada <sawada.m...@gmail.com> wrote in <CAD21AoC1Ztdbp1v-qEnRn=rxac0m6zatb4cj8ryg+dvs4ma...@mail.gmail.com> > On Fri, Sep 30, 2016 at 7:08 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Alvaro Herrera <alvhe...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers