Re: fix for pg_upgrade
От | Bruce Momjian |
---|---|
Тема | Re: fix for pg_upgrade |
Дата | |
Msg-id | 201109281648.p8SGmSM27014@momjian.us обсуждение исходный текст |
Ответ на | Re: fix for pg_upgrade (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: fix for pg_upgrade
|
Список | pgsql-hackers |
Bruce Momjian wrote: > OK, so it fails for all tables and you are using the newest version. > Thanks for all your work. I am now guessing that pg_upgrade 9.1.X is > just broken on Windows. > > Perhaps the variables set by pg_upgrade_support.so are not being passed > into the server variables? I know pg_upgrade 9.0.X worked on Windows > because EnterpriseDB did extensive testing recently on this. Has > anyone used pg_upgrade 9.1.X on Windows? OK, I have a new theory. postmaster.c processes the -b (binary-upgrade) flag by setting a C variable: case 'b': /* Undocumented flag used for binary upgrades */ IsBinaryUpgrade = true; break; I am now wondering if this variable is not being passed down to the sessions during Win32's EXEC_BACKEND. Looking at the other postmaster settings, these set GUC variables, which I assume are passed down. Can someone confirm this? How should this be fixed? FYI, the binary-upgrade set() functions will not operate unless the -b option is enabled, which explains the failure the reporter is seeing. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
В списке pgsql-hackers по дате отправления: