On Fri, Sep 30, 2016 at 6:40 PM, Thomas Kellerer <spam_ea...@gmx.net> wrote: > Tom Lane schrieb am 29.09.2016 um 23:10: >> Thomas Kellerer <spam_ea...@gmx.net> writes: >>> for some reason pg_upgrade failed on Windows 10 for me, with an error >>> message that one specifc _vm file couldn't be copied. >> >> Hmm ... a _vm file would go through rewriteVisibilityMap(), which is new >> code for 9.6 and hasn't really gotten that much testing. Its error >> reporting is shamefully bad --- you can't tell which step failed, and >> I wouldn't even put a lot of faith in the errno being meaningful, >> considering that it does close() calls before capturing the errno. >> >> But what gets my attention in this connection is that it doesn't >> seem to be taking the trouble to open the files in binary mode. >> Could that lead to the reported failure? Not sure, but it seems >> like at the least it could result in corrupted VM files. > > I did this on two different computers, one with Windows 10 the other with > Windows 7. > (only test-databases, so no real issue anyway) > > In both cases running a "vacuum full" for the table in question fixed the > problem and pg_upgrade finished without problems.
Because vacuum full removes the _vm file, pg_upgrade completed job successfully. If you still have the _vm file ("d:/Daten/db/pgdata95/base/16410/85358_vm") that lead an error, is it possible that you check if there is '\r\n' [0d 0a] character in that _vm file or share that _vm file with us? Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers