Re: fix for pg_upgrade
От | Alvaro Herrera |
---|---|
Тема | Re: fix for pg_upgrade |
Дата | |
Msg-id | 1317257702-sup-3707@alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: fix for pg_upgrade (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: fix for pg_upgrade
|
Список | pgsql-hackers |
Excerpts from Bruce Momjian's message of mié sep 28 13:48:28 -0300 2011: > 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? Well, you could compile it with -DEXEC_BACKEND to test it for yourself. > How should this be fixed? Maybe it should be part of struct BackendParameters. -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
В списке pgsql-hackers по дате отправления: