Re: ERROR - Upgrading Postgresql 8.4.3 to Postgressql 9.1.4

On Tue, Aug 14, 2012 at 04:27:45PM -0400, Freddie Burgess wrote:
> We are trying to upgrade our production postgres database instance that is
> approximately 4TB in size and it contains various table partition structures.;
> a separate tablespace for each partition. We were initially successful in
> performing the upgrade using pg_upgrade with both the link and copy options in
> our development environment, but that environment has a different hardware
> configuration {DAS storage and centOS operating system and dedicated server}
> than what is configured in production.
>
>
>
> When we attempted to upgrade using pg_upgrade with the link option on our
> production database. Our Production database is configured with RHEL 5.4, NAS
> storage; configured utilizing a symlink that references the file system on the
> network, and VMWare.
>
>
>
> We ran the pg_upgrade procedures, and it completed to quickly (less than 10
> mins)

That is normal for link mode --- it is using hard links for the data
files.

> - pg_upgrade (using the link option) is supposed to merge the legacy (8.4.3) DB
> cluster with the new, empty (9.1.4) cluster.

Yes.

> - Both databases clusters were being identified as 8.4.3 clusters AFTER the
> upgrade. This was strange, we do not have an explanation. It acted as if the
> upgrade downgraded the 9.1.4 cluster to 8.4.3.

That is very odd, and I have never heard of that problem before.

> - At completion, the DB files were unusable. They would not start under 9.1.4
> or 8.4.3.
>
>
>
> Could our production server’s hardware configuration possibility be the culprit
> responsible for this upgrade failure?

I can't see how, unless you were somehow using the NAS in a way that
didn't allow hard links, but I am unclear how that would happen, and
pg_upgrade checks for that.

I guess the big question is how is production different from testing,
and how does the new server identify itself as 8.4 if you can't connect
to it. Something is obviously majorly messed up.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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