Re: pg_upgrade diffs on WIndows
От | Bruce Momjian |
---|---|
Тема | Re: pg_upgrade diffs on WIndows |
Дата | |
Msg-id | 20120905005633.GV24132@momjian.us обсуждение исходный текст |
Ответ на | Re: pg_upgrade diffs on WIndows (Andrew Dunstan <andrew@dunslane.net>) |
Список | pgsql-hackers |
On Tue, Sep 4, 2012 at 08:46:53PM -0400, Andrew Dunstan wrote: > > On 09/04/2012 03:44 PM, Andrew Dunstan wrote: > > > >On 09/04/2012 03:09 PM, Andrew Dunstan wrote: > >>I realized this morning that I might have been a bit cavalier in > >>using dos2unix to smooth away differences in the dumpfiles > >>produced by pg_upgrade. Attached is a dump of the diff if this > >>isn't done, with Carriage Returns printed as '*' to make them > >>visible. As can be seen, in function bodies dump2 has the > >>Carriage Returns doubled. I have not had time to delve into how > >>this comes about, and I need to attend to some income-producing > >>activity for a bit, but I'd like to get it cleaned up ASAP. We > >>are under the hammer for 9.2, so any help other people can give > >>on this would be appreciated. > >> > > > > > >Actually, I have the answer - it's quite simple. We just need to > >open the output files in binary mode when we split the dumpall > >file. The attached patch fixes it. I think we should backpatch the > >first part to 9.0. > > > > > OK, nobody else has reacted. I've spoken to Bruce and he seems happy > with it, although, TBH, whe I talked to him I thought I understood > it and now I'm not so sure. So we have 3 possibilities: leave it as > is with an error-hiding hack in the test script, apply this patch > which removes the hack and applies a fix that apparently works but > which confuses us a bit, or go back to generating errors. The last > choice would mean I would need to turn off pg_ugrade testing on > Windows pending a fix. And we have to decide pretty much now so we > can get 9.2 out the door. I am very concerned about putting something into pg_upgrade that we don't fully understand. Adding stuff to pg_upgrade that we think we understand is risky enough, as we have seen in the pg_upgrade churn of the past week. Let's work on chat to find the complete details --- same goes for the log file change we are not sure about either. pg_upgrade is so complicated that I have learned that if we don't fully understand something, it can affect things we don't anticipate. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
В списке pgsql-hackers по дате отправления: