Thread: pg_upgrade v9.1 issues
I have 2 instances of postgres installed on same machine under Vista and have run into the following issues when trying to migrate my data from one instance into the other.... 1) If the upgrade process fails, the postmaster.tid file may remain even though the postmaster service is no longer running. I have to manually delete it to re-try. This may occur in either the source or target area. 2) Recommend adding additional parameters to allow specifying target and source roles & pw's. I was getting errors when the same role does not exist in both instances. 3) Received the following error ********* C:\Program Files\PostgreSQL\9.1\bin>pg_upgrade --old-datadir "D:\servoy6\application_server\database" --new-datadir "c:\program files\postgresql\9.1\data" --old-bindir "D:\servoy6\application_server\postgres_db\bin" --new-bindir "c:\program files\postgresql\9.1\bin" Performing Consistency Checks ----------------------------- Checking current, bin, and data directories ok Checking cluster versions ok Checking database user is a superuser ok Checking for prepared transactions ok Checking for reg* system oid user data types ok Checking for contrib/isn with bigint-passing mismatch ok Creating catalog dump ok There were problems executing ""D:\servoy6\application_server\postgres_db\bin/pg_ctl" -w -l "nul" -D "D:\servoy6\application_server\database" stop >> "nul" 2>&1" Failure, exiting ********* Note: I don't know if this matters, but the target (new v9.1) source has instance set to start automatically in services. The source (old v9.0) is not. The error is referring to the source instance. Apparently, it is trying to shut the service down and if it is already down, then it errors out as opposed to continuing on. Thanks, Larry Long -- View this message in context: http://postgresql.1045698.n5.nabble.com/pg-upgrade-v9-1-issues-tp4892564p4892564.html Sent from the PostgreSQL - bugs mailing list archive at Nabble.com.
lalong wrote: > I have 2 instances of postgres installed on same machine under Vista and have > run into the following issues when trying to migrate my data from one > instance into the other.... > > 1) If the upgrade process fails, the postmaster.tid file may remain even > though the postmaster service is no longer running. I have to manually > delete it to re-try. This may occur in either the source or target area. That is odd --- even if the pid file remains, it shouldn't prevent the new server from starting. Can you reproduce it using manual commands or is it something specific to pg_upgrade? -l log will show you the commands pg_upgrade is running. > 2) Recommend adding additional parameters to allow specifying target and > source roles & pw's. I was getting errors when the same role does not exist > in both instances. Well, I am not sure how that happened if the new cluster was empty on start. Can you be more specific? > 3) Received the following error > ********* > C:\Program Files\PostgreSQL\9.1\bin>pg_upgrade --old-datadir > "D:\servoy6\application_server\database" --new-datadir "c:\program > files\postgresql\9.1\data" --old-bindir > "D:\servoy6\application_server\postgres_db\bin" --new-bindir "c:\program > files\postgresql\9.1\bin" > Performing Consistency Checks > ----------------------------- > Checking current, bin, and data directories ok > Checking cluster versions ok > Checking database user is a superuser ok > Checking for prepared transactions ok > Checking for reg* system oid user data types ok > Checking for contrib/isn with bigint-passing mismatch ok > Creating catalog dump ok > > There were problems executing > ""D:\servoy6\application_server\postgres_db\bin/pg_ctl" -w -l "nul" -D > "D:\servoy6\application_server\database" stop >> "nul" 2>&1" > Failure, exiting > ********* That is odd. Does it work if you run it manually? > Note: I don't know if this matters, but the target (new v9.1) source has > instance set to start automatically in services. The source (old v9.0) is > not. The error is referring to the source instance. Apparently, it is > trying to shut the service down and if it is already down, then it errors > out as opposed to continuing on. Well, both servers should be down on start, as mentioned in the pg_upgrade documentation. I don't see how the auto-start would affect that. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
I am having the same exact problem, migrating from 8.4SS to 9.1 . @Bruce_Momjian: Do you have a solution for this ?? I have also opened a thread for this because I didn't find this thread before. http://postgresql.1045698.n5.nabble.com/Upgrade-Postgres-8-4SS-gt-gt-9-1-td5151661.html -- View this message in context: http://postgresql.1045698.n5.nabble.com/pg-upgrade-v9-1-issues-tp4892564p5151762.html Sent from the PostgreSQL - bugs mailing list archive at Nabble.com.
On Tue, Jan 17, 2012 at 06:38:46AM -0800, shitake wrote: > I am having the same exact problem, migrating from 8.4SS to 9.1 . > > @Bruce_Momjian: Do you have a solution for this ?? > > I have also opened a thread for this because I didn't find this thread > before. > > http://postgresql.1045698.n5.nabble.com/Upgrade-Postgres-8-4SS-gt-gt-9-1-td5151661.html Well, the first problem, which you solved, was that somehow the system was not setup for 'trust'. The second problem is that the server isn't stopping: There were problems executing ""D:/Program Files/PostgresPlus/8.4SS/bin/pg_ctl" -w -l "nul" -D "D:/Program Files/PostgresPlus/8.4SS/data" -m fast stop ------ >> "nul" 2>&1" Note the "stop" word at the end of the third line. It is odd that stopping is a problem, but it is on Windows, so perhaps there is some odd configuration on that machine. You might try starting and stopping the system manually using the commands displayed and see if that works. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +