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

Re: fix for pg_upgrade

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: panam <panam(at)gmx(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: fix for pg_upgrade
Date: 2011-09-28 16:48:28
Message-ID: 201109281648.p8SGmSM27014@momjian.us (view raw or flat)
Thread:
Lists: 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(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: Gurjeet SinghDate: 2011-09-28 17:30:22
Subject: Re: feature request: auto savepoint for interactive psql when in transaction.
Previous:From: Tom LaneDate: 2011-09-28 16:40:10
Subject: Re: Feature proposal: www_fdw

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