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

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. +