Skip site navigation (1) Skip section navigation (2)

Re: fix for pg_upgrade

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, panam <panam(at)gmx(dot)net>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: fix for pg_upgrade
Date: 2011-09-29 21:22:34
Message-ID: 201109292122.p8TLMY706800@momjian.us (view raw or flat)
Thread:
Lists: pgsql-hackers
> Alvaro Herrera wrote:
> >
> > Excerpts from Bruce Momjian's message of mi<C3><A9> 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.

Applied, and backpatched to 9.1.X.  Thanks for the report.  The fix will
be in 9.1.2.

-- 
  Bruce Momjian  <bruce(at)momjian(dot)us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +

In response to

Responses

pgsql-hackers by date

Next:From: Alexander KorotkovDate: 2011-09-29 21:29:06
Subject: Re: Re: Optimizing pg_trgm makesign() (was Re: WIP: Fast GiST index build)
Previous:From: Alexander KorotkovDate: 2011-09-29 21:20:47
Subject: Re: Re: Optimizing pg_trgm makesign() (was Re: WIP: Fast GiST index build)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group