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

Re: fix for pg_upgrade

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: panam <panam(at)gmx(dot)net>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: fix for pg_upgrade
Date: 2011-09-29 00:56:40
Message-ID: 1317257702-sup-3707@alvh.no-ip.org (view raw or flat)
Thread:
Lists: 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(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

In response to

Responses

pgsql-hackers by date

Next:From: Joachim WielandDate: 2011-09-29 02:16:35
Subject: Re: synchronized snapshots
Previous:From: Jaime CasanovaDate: 2011-09-28 23:55:31
Subject: Re: Updated version of pg_receivexlog

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