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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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. +
From | Date | Subject | |
---|---|---|---|
Next Message | Gurjeet Singh | 2011-09-28 17:30:22 | Re: feature request: auto savepoint for interactive psql when in transaction. |
Previous Message | Tom Lane | 2011-09-28 16:40:10 | Re: Feature proposal: www_fdw |