On Fri, Sep 30, 2016 at 1:26 PM, Kyotaro HORIGUCHI <horiguchi.kyot...@lab.ntt.co.jp> wrote: > 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. >
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
