Upgrade to RedHat 9.0 broke PostgreSQL
I upgraded one of my RedHat machines from 8.0 to 9.0 and PostgreSQL
stopped working, with the following error message (reformatted here
for readability):
An old version of the database format was found.
You need to upgrade the data format before using PostgreSQL.
See (Your System's documentation
directory)/postgresql-7.3/README.rpm-dist for more information.
All I could find in that document which was relevant was:
These RPMs no longer support any sort of upgrading process other
than that documented in the regular documentation. That is, you
must dump, upgrade, initdb, and restore your data. The 7.2 to 7.3
migration can be quite difficult, even to the point of requiring
hand-editing of the dumpfile.
Thus, the 7.3 postgresql-server RPM specifically conflicts with
prior versions. The old server subpackage must be removed first,
the new package installed, and the data restored from dump.
Not the sort of thing I expected from an upgrade of the OS. So now
I'm faced with a Catch-22 dilemma: I need to dump the data with a
version of the database which is no longer on the machine.
I went back and pulled out my RedHat 8.0 CDs and tried to do a forced
downgrade of PostgreSQL to 7.2, but that failed because of dependency
conflicts.
So I pulled down the sources for 7.2.4, unpacked them, and ran
./configure and make. That failed, too, with the following errors:
...
gcc ... -o postgres
commands/SUBSYS.o(.text+0x41ce): In function `DoCopy':
: undefined reference to `errno'
commands/SUBSYS.o(.text+0x41d4): In function `DoCopy':
: undefined reference to `errno'
commands/SUBSYS.o(.text+0x42db): In function `DoCopy':
: undefined reference to `errno'
commands/SUBSYS.o(.text+0x42e1): In function `DoCopy':
: undefined reference to `errno'
collect2: ld returned 1 exit status
[... etc.]
So I'm stuck. Can I get two things, please?
1. A clue on how to get out of this box.
2. An explanation for why the box is necessary? I mean, it
would have been nice to have left behind sufficient tools
to do the dump PostgreSQL is requiring. If they were left
behind, it would have been nice if they were easier to find.
Apologies if this is in the FAQ -- I did look. I also looked at
http://www.postgresql.org/docs/view.php?version=7.3&idoc=1&file=admin.html
but the word "upgrade" doesn't appear anywhere in that detailed
table of contents.
Thanks in advance for any assistance.
Bob
BK
Its quite surprising that 7.2.4 is not compilable under
redhat 9.0 , which version of gcc does it come with?
yes you will need to dump the database using pg7.2.x
and reload in 7.3.x.
I can suggest one thing try to install 7.2.x on redhat
using RPMS (since compilation already falied)
then dump pg database in an sql file. move the data folders
out of the way , Install 7.3.2 . initdb and restore the data.
regds
mallah.
I upgraded one of my RedHat machines from 8.0 to 9.0 and PostgreSQL stopped working, with the
following error message (reformatted here for readability):An old version of the database format was found.
You need to upgrade the data format before using PostgreSQL.
See (Your System's documentation
directory)/postgresql-7.3/README.rpm-dist for more information.All I could find in that document which was relevant was:
These RPMs no longer support any sort of upgrading process other than that documented in the
regular documentation. That is, you must dump, upgrade, initdb, and restore your data. The
7.2 to 7.3 migration can be quite difficult, even to the point of requiring hand-editing of
the dumpfile.Thus, the 7.3 postgresql-server RPM specifically conflicts with prior versions. The old
server subpackage must be removed first, the new package installed, and the data restored
from dump.Not the sort of thing I expected from an upgrade of the OS. So now I'm faced with a Catch-22
dilemma: I need to dump the data with a
version of the database which is no longer on the machine.I went back and pulled out my RedHat 8.0 CDs and tried to do a forced downgrade of PostgreSQL
to 7.2, but that failed because of dependency conflicts.So I pulled down the sources for 7.2.4, unpacked them, and ran
./configure and make. That failed, too, with the following errors:...
gcc ... -o postgres
commands/SUBSYS.o(.text+0x41ce): In function `DoCopy':
: undefined reference to `errno'
commands/SUBSYS.o(.text+0x41d4): In function `DoCopy':
: undefined reference to `errno'
commands/SUBSYS.o(.text+0x42db): In function `DoCopy':
: undefined reference to `errno'
commands/SUBSYS.o(.text+0x42e1): In function `DoCopy':
: undefined reference to `errno'
collect2: ld returned 1 exit status[... etc.]
So I'm stuck. Can I get two things, please?
1. A clue on how to get out of this box.
2. An explanation for why the box is necessary? I mean, it
would have been nice to have left behind sufficient tools
to do the dump PostgreSQL is requiring. If they were left
behind, it would have been nice if they were easier to find.Apologies if this is in the FAQ -- I did look. I also looked at
http://www.postgresql.org/docs/view.php?version=7.3&idoc=1&file=admin.html but the word
"upgrade" doesn't appear anywhere in that detailed
table of contents.Thanks in advance for any assistance.
Bob
---------------------------(end of broadcast)--------------------------- TIP 3: if
posting/reading through Usenet, please send an appropriate subscribe-nomail command to
majordomo@postgresql.org so that your
message can get through to the mailing list cleanly
-----------------------------------------
Get your free web based email at trade-india.com.
"India's Leading B2B eMarketplace.!"
http://www.trade-india.com/
On Sat, 12 Apr 2003 mallah@trade-india.com wrote:
BK
Its quite surprising that 7.2.4 is not compilable under redhat 9.0 ,
which version of gcc does it come with?
3.2.2-5.
yes you will need to dump the database using pg7.2.x and reload in
7.3.x.I can suggest one thing try to install 7.2.x on redhat using RPMS
(since compilation already falied)
As I noted in the original posting I had tried this, and the
dependencies were hairy enough that I figured I'd be better off with
building from the source tarball. I went back and waded through the RPM
dependency message and finally got it all sorted out and working, but it
would be nice to know what's going on with the linker failures (and even
nicer not to have to go through the downgrade at all).
Thanks for the reply.
--
Bob Kline
mailto:bkline@rksystems.com
http://www.rksystems.com
On Fri, 2003-04-11 at 09:57, bkline@rksystems.com wrote:
gcc ... -o postgres
commands/SUBSYS.o(.text+0x41ce): In function `DoCopy':
: undefined reference to `errno'
commands/SUBSYS.o(.text+0x41d4): In function `DoCopy':
: undefined reference to `errno'
commands/SUBSYS.o(.text+0x42db): In function `DoCopy':
: undefined reference to `errno'
commands/SUBSYS.o(.text+0x42e1): In function `DoCopy':
: undefined reference to `errno'
collect2: ld returned 1 exit status
Applying this patch should allow PostgreSQL 7.2.x to compile under RH9:
Cheers,
Neil
On 11 Apr 2003, Neil Conway wrote:
On Fri, 2003-04-11 at 09:57, bkline@rksystems.com wrote:
gcc ... -o postgres
commands/SUBSYS.o(.text+0x41ce): In function `DoCopy':
: undefined reference to `errno'
commands/SUBSYS.o(.text+0x41d4): In function `DoCopy':
: undefined reference to `errno'
commands/SUBSYS.o(.text+0x42db): In function `DoCopy':
: undefined reference to `errno'
commands/SUBSYS.o(.text+0x42e1): In function `DoCopy':
: undefined reference to `errno'
collect2: ld returned 1 exit statusApplying this patch should allow PostgreSQL 7.2.x to compile under RH9:
Excellent! Thanks very much.
--
Bob Kline
mailto:bkline@rksystems.com
http://www.rksystems.com
On Friday 11 April 2003 09:57, bkline@rksystems.com wrote:
I upgraded one of my RedHat machines from 8.0 to 9.0 and PostgreSQL
stopped working,
[note: subject changed. There is no 'Red Hat 9.0'. There is, however, a 'Red
Hat Linux 9']
It's in the Release notes (or it should be, as it's been in every Red Hat
Linux release notes since a couple of years ago) that one should do a pg_dump
of all data before upgrading.
These RPMs no longer support any sort of upgrading process other
than that documented in the regular documentation. That is, you
must dump, upgrade, initdb, and restore your data. The 7.2 to 7.3
migration can be quite difficult, even to the point of requiring
hand-editing of the dumpfile.
I had a semi-automatic upgrade mechanism for previous versions. Going from
7.2 to 7.3 can be very difficult to automate (see the thread 'Upgrade Rant'
in the archives of HACKERS for more details, and for a look at the
unwillingness of some of the developers to consider supporting better
upgrades). My plan was to be able to provide older releases of PostgreSQL
for newer OS's as they came out. I simply have not had the time to build
7.2.x RPM's for RHL 9 as yet. Sorry.
Thus, the 7.3 postgresql-server RPM specifically conflicts with
prior versions. The old server subpackage must be removed first,
the new package installed, and the data restored from dump.
Unfortunately, due to a bug in RPM itself, this safety mechanism I tried to
implement did not work the way it should. The idea was that the OS upgrade
process should not even do the postgresql-server upgrade. That fell over due
to RPM itself not obeying the conflicts directive for instances of the same
package. ARgh.
Not the sort of thing I expected from an upgrade of the OS. So now
I'm faced with a Catch-22 dilemma: I need to dump the data with a
version of the database which is no longer on the machine.
Been there; done that. Four years ago. This is historical behavior with Red
Hat Linux, since Red Hat 5.1 bumped the version from 5.0's 6.2.1 to 6.3.2.
Then Red Hat 6.0 shipped 6.4.2. And then Red Hat 6.1 shipped PostgreSQL
6.5.... (my first RPMset to make it into the Red Hat distribution). And so
on. This is not unusual. Unfortunately.
I went back and pulled out my RedHat 8.0 CDs and tried to do a forced
downgrade of PostgreSQL to 7.2, but that failed because of dependency
conflicts.
Yes. Thank you Red Hat.
So I pulled down the sources for 7.2.4, unpacked them, and ran
./configure and make. That failed, too, with the following errors:
And this is the bummer.
1. A clue on how to get out of this box.
Build 7.2.4 from source or source RPM, using the patch previously posted. OR
wait a few days until I can build 7.2.4 RPM's for RHL9 (which I need anyway
for another project; it will just be a few days, though, before I can get to
it).
2. An explanation for why the box is necessary? I mean, it
would have been nice to have left behind sufficient tools
to do the dump PostgreSQL is requiring. If they were left
behind, it would have been nice if they were easier to find.
A partial solution is a fixed version of pg_upgrade, but developer interest in
doing something this useful is nearly nil. (I say 'nearly' because Bruce
Momjian has expressed a little interest in getting it working (and he wrote
it in the first place)).
This issue has been beat to death, on numerous occasions, for several years.
I have gotten into flame mode more than once over the obnoxiousness of our
pseudo-upgrade procedure. Now that a FreeBSD user has reported the same sort
of issue using 'portupgrade' (Finally it's not just an RPM thing! (or a
Debian thing!)) maybe some of the *BSD-using developers will see the need for
a real upgrade process instead of the junk we have now.
So, I took out the kludge I had in the RPMset. I tried to prevent the issue;
that didn't work because the rpm program didn't do what I directed it to do.
And now there are going to be a lot of upset users just like you. All of
which could have been prevented if developers had had a little foresight into
how big of a problem this would become. Especially with the upgrade to 7.3.
7.3 needed robust upgrading. That window of opportunity has been missed.
And it's not something that can be kludged. Designing for upgradability has
to become endemic; handling it on the surface with pg_upgrade, no matter how
good pg_upgrade becomes, is still a kludge. Old data should be readable with
the new backend -- period. The backends must be able to reconstruct what is
needed for a new version -- seamlessly and transparently -- for it to work
properly. And this means that great care and forethought must be exercised
in the development of PostgreSQL. This is not currently being done with an
eye towards upgradability. And upgrades will continue to be royal pains
until all the developers begin caring about this distinctly user issue.
(This conclusion was reached at the end of the last time we beat this nearly
dead horse in the Upgrading Rant thread due to the nature of PostgreSQL's
system catalogs and the extreme extensibility PostgreSQL provides.)
So, unless some things change at fundamental levels, it's going to remain a
problem. The lesson is to always do an ASCII dump before an OS upgrade.
PostgreSQL is not the only program that can be borked in an OS upgrade,
either.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
On Sat, 12 Apr 2003, Lamar Owen wrote:
[ Very throrough and thoughtful reply, ending ...]
So, unless some things change at fundamental levels, it's going to
remain a problem. The lesson is to always do an ASCII dump before an
OS upgrade. PostgreSQL is not the only program that can be borked in
an OS upgrade, either.
Thanks very much for your excellent reply, and for your efforts to make
things better. I've learned my lesson for the future. I hope these
problems won't drive away too many prospective PostgreSQL users.
--
Bob Kline
mailto:bkline@rksystems.com
http://www.rksystems.com
On Friday 11 April 2003 23:06, Bob Kline wrote:
On 11 Apr 2003, Neil Conway wrote:
Applying this patch should allow PostgreSQL 7.2.x to compile under RH9:
http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/backend/comma
nds/copy.c.diff?only_with_tag=REL7_2_STABLE&r2=1.145.2.2&r1=1.145.2.1&f=c
Excellent! Thanks very much.
RPMs for 7.2.4 built on Red Hat Linux 9 are uploading now to
ftp.postgresql.org. They are in the directory
/pub/binary/v7.2.4/RPMS/redhat-9, as 7.2.4-2PGDG. Source RPM is in
/pub/binary/v7.2.4/RPMS/SRPMS
There are a few missing files fixed by this as well as just being compiled
under RHL9. I will upload RHL 8.0 versions if demand is there. Likewise,
versions for RHL7.3 and RHL6.2 may be arrangable, if the demand is there.
Note that the RHL9 RPMset does not include postgresql-perl due to some issues
with my build setup (that is, I don't want to build as root since I have a
working and in use 7.3.2 setup on my buildbox, and the perl subpackage won't
build as a normal user). As this RPMset is meant for those who upgraded to
RHL9 and can't get their data anymore, this isn't a terrible issue:
'downgrade' the postgresql RPMs (using --oldpackage), dump your data, upgrade
back, and try to restore. Iterate until working... :-) Make a copy of
/var/lib/pgsql/data first, please.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
Bob Kline wrote:
On Sat, 12 Apr 2003, Lamar Owen wrote:
[ Very throrough and thoughtful reply, ending ...]
So, unless some things change at fundamental levels, it's going to
remain a problem. The lesson is to always do an ASCII dump before an
OS upgrade. PostgreSQL is not the only program that can be borked in
an OS upgrade, either
What a mess...
RH has fouled up a lot of stuff lately...
I'm not even going to go there...
:-(
Show quoted text
Thanks very much for your excellent reply, and for your efforts to make
things better. I've learned my lesson for the future. I hope these
problems won't drive away too many prospective PostgreSQL users.
On Tuesday 15 April 2003 14:23, Guy Fraser wrote:
What a mess...
RH has fouled up a lot of stuff lately...
I'm not even going to go there...
It's as much a problem with other RPM-based distributions of Linux as it is
with Red Hat. And I am of the strong opinion that it is just as much the
fault of the way PostgreSQL forces upgrades as it is a fault with any
particular distributor.
Even a straight portupgrade on FreeBSD is broken. It's a mess because of the
way PostgreSQL needs to be upgraded.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
Most OS people screw things up between major revisions.
From watching friends and also this list, the lesson is just what you stated:
Do a full system backup before any major revision changes in any software
whatsoever. It's saved my but once. I lost the entire registry in windows95
once. Fortunately, after doing a file compare, I found that was the only file
corrupted, and restored a 3 month old one. I had to reinstall a few programs and
delete the registry entries for some that were no longer resident. But it was
better than reinstalling EVERYTHING, including OS patches.
At the current moment, I keep a full harddrive backup of the harddrives in my
box on older machines. What to do with WinXP, i don't know yet. In fact, I don't
know how to do a drive copy with Linux either. something else to learn, I guess.
Guy Fraser wrote:
Show quoted text
Bob Kline wrote:
On Sat, 12 Apr 2003, Lamar Owen wrote:
[ Very throrough and thoughtful reply, ending ...]
So, unless some things change at fundamental levels, it's going to
remain a problem. The lesson is to always do an ASCII dump before an
OS upgrade. PostgreSQL is not the only program that can be borked in
an OS upgrade, eitherWhat a mess...
RH has fouled up a lot of stuff lately...
I'm not even going to go there...
:-(Thanks very much for your excellent reply, and for your efforts to make
things better. I've learned my lesson for the future. I hope these
problems won't drive away too many prospective PostgreSQL users.---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
On Tuesday 15 April 2003 14:35, Dennis Gearon wrote:
At the current moment, I keep a full harddrive backup of the harddrives in
my box on older machines. What to do with WinXP, i don't know yet. In fact,
I don't know how to do a drive copy with Linux either. something else to
learn, I guess.
Norton Ghost.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
When you say "forces upgrades" what do you mean?
I might do things differently- I download the tarball, compile, dump and restore
my system. I've never have Postgres **not** compile on my Slackware boxes but
I've had **tons** of issues with RPM disto's (I've consulted on RedHat &
Mandrake personally) with even smaller packages things so I don't use it much.
Seems to me you should **always** be able to compile software.
-$0.02
--
Keith C. Perry
Director of Networks & Applications
VCSN, Inc.
http://vcsn.com
Quoting Lamar Owen <lamar.owen@wgcr.org>:
On Tuesday 15 April 2003 14:23, Guy Fraser wrote:
What a mess...
RH has fouled up a lot of stuff lately...
I'm not even going to go there...It's as much a problem with other RPM-based distributions of Linux as it is
with Red Hat. And I am of the strong opinion that it is just as much the
fault of the way PostgreSQL forces upgrades as it is a fault with any
particular distributor.Even a straight portupgrade on FreeBSD is broken. It's a mess because of the
way PostgreSQL needs to be upgraded.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
____________________________________
This email account is being host by:
VCSN, Inc : http://vcsn.com
Thanks!
It doesn't require norton to be installed, does it? Norton just slows machines
down and adds too many useless bells and whistles for the sake of marketing.
Lamar Owen wrote:
Show quoted text
On Tuesday 15 April 2003 14:35, Dennis Gearon wrote:
At the current moment, I keep a full harddrive backup of the harddrives in
my box on older machines. What to do with WinXP, i don't know yet. In fact,
I don't know how to do a drive copy with Linux either. something else to
learn, I guess.Norton Ghost.
I heard that the debian rev system is MUCH better, but never got accepted
because of the market weight of RH. Is this so?
Network Administrator wrote:
Show quoted text
When you say "forces upgrades" what do you mean?
I might do things differently- I download the tarball, compile, dump and restore
my system. I've never have Postgres **not** compile on my Slackware boxes but
I've had **tons** of issues with RPM disto's (I've consulted on RedHat &
Mandrake personally) with even smaller packages things so I don't use it much.Seems to me you should **always** be able to compile software.
-$0.02
On Tue, 2003-04-15 at 20:35, Lamar Owen wrote:
At the current moment, I keep a full harddrive backup of the harddrives in
my box on older machines. What to do with WinXP, i don't know yet. In fact,
I don't know how to do a drive copy with Linux either. something else to
learn, I guess.Norton Ghost.
rsync - saved my life more than once. On Linux you only need to back up
/home and /etc for basics and if you want to be more complicated you
rsync the rest too.
Of course your PostgreSQL data is on another drive which is mirrored...
Cheers
Tony Grant
I've heard that about Debian and SUSE too actually. It still (unfortunately)
comes down to market penetration- even for open source. I just tell folks to
try our a couple of disto or OS' in general an see which one mates to your
personality best...
Of course I am 3-0 in converting people from RedHat/Mandrake to Slackware.
*grin*
Quoting Dennis Gearon <gearond@cvc.net>:
I heard that the debian rev system is MUCH better, but never got accepted
because of the market weight of RH. Is this so?Network Administrator wrote:
When you say "forces upgrades" what do you mean?
I might do things differently- I download the tarball, compile, dump and
restore
my system. I've never have Postgres **not** compile on my Slackware boxes
but
I've had **tons** of issues with RPM disto's (I've consulted on RedHat &
Mandrake personally) with even smaller packages things so I don't use itmuch.
Seems to me you should **always** be able to compile software.
-$0.02
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
--
Keith C. Perry
Director of Networks & Applications
VCSN, Inc.
http://vcsn.com
____________________________________
This email account is being host by:
VCSN, Inc : http://vcsn.com
On Tue, 2003-04-15 at 20:47, Network Administrator wrote:
When you say "forces upgrades" what do you mean?
I might do things differently- I download the tarball, compile, dump and restore
my system. I've never have Postgres **not** compile on my Slackware boxes but
I've had **tons** of issues with RPM disto's (I've consulted on RedHat &
Mandrake personally) with even smaller packages things so I don't use it much.Seems to me you should **always** be able to compile software.
I have never been able to compile (with regularity) PostgreSQL on Redhat
boxes since 1997. Thank god for rpm...
1. Redhat 8 is great - if you need the new POSIX threads compile a
2.4.20 kernel
2. I tried installing debian a few times, Slackware once. I was
beginning with Linux. Redhat went on the machine without a sweat. *ask
me what that machine was if you dare
3. PostgreSQL runs great on lots of systems - my dev server is Mac OS X
10.2.5 and the client is redhat 8. There are tons of Linuxen there are
people who compile and people who double click. Big deal...
Cheers
Tony Grant
--
www.tgds.net Library management software toolkit,
redhat linux on Sony Vaio C1XD,
Dreamweaver MX with Tomcat and PostgreSQL
Quoting Tony Grant <tony@tgds.net>:
<stuff deleted>
3. PostgreSQL runs great on lots of systems - my dev server is Mac OS X
10.2.5 and the client is redhat 8. There are tons of Linuxen there are
people who compile and people who double click. Big deal...Cheers
Tony Grant
--
www.tgds.net Library management software toolkit,
redhat linux on Sony Vaio C1XD,
Dreamweaver MX with Tomcat and PostgreSQL
Oh now that is sweet. I was just talking to someone about getting a dual G4
with OS X and PostgreSQL & Apache2. I have'nt had the pleasure yet- one day...
--
Keith C. Perry
Director of Networks & Applications
VCSN, Inc.
http://vcsn.com
____________________________________
This email account is being host by:
VCSN, Inc : http://vcsn.com
Or you can use a run-time Linux CD (or boot floppies) and use the "dd" program
in Linux to image your drive. I built an imaging solution with a modified
Slackware 8.0 run-time CD (disk 2) this way. Its biased for Dell (and all
they're RAID stuff) but if your hardware is not too proprietary you can pretty
much do things right with the stock CD or newer boot floppies...
You could even compress the image to save space.
Quoting Lamar Owen <lamar.owen@wgcr.org>:
On Tuesday 15 April 2003 14:35, Dennis Gearon wrote:
At the current moment, I keep a full harddrive backup of the harddrives in
my box on older machines. What to do with WinXP, i don't know yet. Infact,
I don't know how to do a drive copy with Linux either. something else to
learn, I guess.Norton Ghost.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
--
Keith C. Perry
Director of Networks & Applications
VCSN, Inc.
http://vcsn.com
____________________________________
This email account is being host by:
VCSN, Inc : http://vcsn.com
