Re: 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(at)momjian(dot)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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +