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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Joachim Wieland | 2011-09-29 02:16:35 | Re: synchronized snapshots |
Previous Message | Jaime Casanova | 2011-09-28 23:55:31 | Re: Updated version of pg_receivexlog |