Re: fix for pg_upgrade
Bruce Momjian <bruce@momjian.us>
From: Bruce Momjian <bruce@momjian.us>
To: Alvaro Herrera <alvherre@commandprompt.com>
Cc: panam <panam@gmx.net>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2011-09-29T03:14:11Z
Lists: pgsql-hackers
Attachments
- /rtmp/pg_upgrade (text/x-diff) patch
Alvaro Herrera wrote: > > 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. Thanks. That's what I did, and tested the failure with -DEXEC_BACKEND, and the fix with the patch, which is attached. I am confident this will fix Windows as well. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +