Thread: 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 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:


http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/backend/commands/copy.c.diff?only_with_tag=REL7_2_STABLE&r2=1.145.2.2&r1=1.145.2.1&f=c

Cheers,

Neil

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 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 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 status
>
> Applying this patch should allow PostgreSQL 7.2.x to compile under RH9:
>
>
http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/backend/commands/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.

--
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...
:-(

>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.
>
>
>

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:
> 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...
> :-(
>
>> 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?
>
> http://archives.postgresql.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

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?
>
> http://archives.postgresql.org
>



____________________________________
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:
> 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:
> 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 it
> much.
> >
> > Seems to me you should **always** be able to compile software.
> >
> > -$0.02
> >
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>


--
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. 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
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faqs/FAQ.html
>


--
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 Tuesday 15 April 2003 14:55, Dennis Gearon wrote:
>     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.

Na, Ghost can be a standalone program.  Ghost 2003 is killer; 2002 (which can
be had for cheap) is very good as well.  I got mine with a motherboard I
purchased last year. (:-O).  And I left it on list for this purpose: Ghost
can image your whole drive.  It can resize Windows partitions.  It makes a
good offline backup tool for PostgreSQL partitions, too.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

On Tuesday 15 April 2003 14:47, Network Administrator wrote:
> When you say "forces upgrades" what do you mean?

PostgreSQL forces you to dump under the old version, then install the new
version, initdb, and restore your data.  Package-based upgrades have extreme
difficulty with the 'dump with previous version' bit, unless the sysadmin/DBA
has done them prior to the package upgrade.  IOW, PostgreSQL forces a
non-standard (as compared with other system services (and user programs, for
that matter)) upgrade path -- virtually all other daemons are capable of
reading the old configs and data files or there is some form of data
migration tool packaged that does not require the old version to use.

When I upgraded to RH8.0 from 7.3 on my production DNS server, the migration
from BIND 8 to BIND 9 was a smooth as silk, all the way down to the $ORIGIN
directives, eliminating the @'s, dropping the redundant IN's, etc.  In fact,
I was not even aware of the differences until I needed to do some maintenance
on a zone file.  Nothing broke, either.

On MySQL, due to the modular storage manager they use, you can migrate table
by table to a newer or just a different storage manager.  But the old data
doesn't become unusable under the new version.  Reconciling his with our
system catalog setup is not going to be easy -- in fact, it will be very
difficult.

> Seems to me you should **always** be able to compile software.

Sure.  You can do this; it complicates the sysadmin's job, however, when your
packaged version of PHP you want to install doesn't recognize that you really
do have PostgreSQL of the required version installed.

Debian's apt package wrapper (dpkg is still at the core) is excellent for
resolving dependencies; Connectiva ported apt to RPM.  See www.freshrpms.net
for apt-get for RPM for various Red Hat versions, including 9.  I use it
myself; particularly useful when you need a third-party app that has tons of
dependencies (such as the ALSA drivers, mplayer, and xine).  'apt-get install
xine' (once apt knows from where you want to pull the packages; already set
up if you download freshrpms' version of apt-get for RPM) and all the
dependencies are automatically resolved (and installed, after your
confirmation).  For a GUI to apt, get synaptic (once you have apt4rpm on your
box, apt-get install synaptic), and you will be amazed.

And the two line incantation:

apt-get update
apt-get upgrade

keeps my system supplied with necessary security errata.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

On Tue, Apr 15, 2003 at 11:56:16AM -0700, Dennis Gearon wrote:
> I heard that the debian rev system is MUCH better, but never got accepted
> because of the market weight of RH. Is this so?

Debian just makes the compromises in another place.  I like the
.deb+apt approach better, myself, but I don't think it has anything
like a magic bullet for this problem.

(This is not to denigrate the excellent work of Oliver Elphick, by
the way.)

A


----
Andrew Sullivan                         204-4141 Yonge Street
Liberty RMS                           Toronto, Ontario Canada
<andrew@libertyrms.info>                              M2P 2A8
                                         +1 416 646 3304 x110

On Tuesday 15 April 2003 15:18, Network Administrator wrote:
> 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...

Ghost can reimage to a drive with a different size and geometry.  It then
touches up the partition tables, but leaves your bootloader in the MBR
intact.  I haven't been able to do that with dd as yet; for identical
geometries dd works well.  I don't have ghost 2003; 2002 couldn't resize
ext2/3 partitions as yet.  2002 can resize NTFS and FAT, however.

I have used Ghost more than once for hard drive upgrades; both Linux and
Win2k, desktop and server.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Quoting Lamar Owen <lamar.owen@wgcr.org>:

> On Tuesday 15 April 2003 14:47, Network Administrator wrote:
> > When you say "forces upgrades" what do you mean?
>
> PostgreSQL forces you to dump under the old version, then install the new
> version, initdb, and restore your data.  Package-based upgrades have extreme
>
> difficulty with the 'dump with previous version' bit, unless the sysadmin/DBA
>
> has done them prior to the package upgrade.  IOW, PostgreSQL forces a
> non-standard (as compared with other system services (and user programs, for
>
> that matter)) upgrade path -- virtually all other daemons are capable of
> reading the old configs and data files or there is some form of data
> migration tool packaged that does not require the old version to use.

Ahhhh, ok.  I see what you're saying.  I guess the way I look at that is that
you have the OS and then you have the stuff that runs on the OS.  I would not
expect PostgreSQL to be "upgradeable" in the same way.  Of course the fact that
you **can** do that is probably very attractive to some sysadmins.  I guess, I'm
 old school.  Give me the source so I can compile for my system.

> When I upgraded to RH8.0 from 7.3 on my production DNS server, the migration
>
> from BIND 8 to BIND 9 was a smooth as silk, all the way down to the $ORIGIN
> directives, eliminating the @'s, dropping the redundant IN's, etc.  In fact,
> I was not even aware of the differences until I needed to do some maintenance
>
> on a zone file.  Nothing broke, either.
>

True, true I had that same experience actually but your already past the
application (named) part here and there for the "compiling" phase, no?  That
named.conf file and associated zone file would be very much like reloading a
database from a dump.  I think the only time I've every had a problem in that
regard is with feilds that were of a "time" type.  I seem to remember emailing
the list years ago about that.  I just ran a program I have against the dump
file to change the field type.

> On MySQL, due to the modular storage manager they use, you can migrate table
>
> by table to a newer or just a different storage manager.  But the old data
> doesn't become unusable under the new version.  Reconciling his with our
> system catalog setup is not going to be easy -- in fact, it will be very
> difficult.

Ok, I what you're saying here.  I must have mis-read the original email 'cause I
thought this a PostgreSQL upgrade not a migration from MySQL- my apologies-
questions though, wouldn't you have to use a dump/restore to move between RDBMS?
 That's the way I've always done things but if there's another way I guess
school is in session for me :)

> > Seems to me you should **always** be able to compile software.
>
> Sure.  You can do this; it complicates the sysadmin's job, however, when your
>
> packaged version of PHP you want to install doesn't recognize that you really
>
> do have PostgreSQL of the required version installed.

This is where I've had the issues- simply not being able to compile source
because something is missing.  In one of the environment I'm in, I was tasked
with getting Progress running on RedHat because Progress said they supported
RedHat- which already is an issue, because a disto should not be the support
point.  It should be the kernel version and other libraries.  In any event I
never got it to work on RedHat because at the time RedHat kernel was an insecure
 one and the next build up did not have the Dell Raid drive available so I
played the typical very corporate game of "finger pointing" (Dell says RedHat
has the driver, RedHat says Dell doesa) for weeks until I finally just built the
thing on Slackware and compiled the driver for the proper kernel.

> Debian's apt package wrapper (dpkg is still at the core) is excellent for
> resolving dependencies; Connectiva ported apt to RPM.  See www.freshrpms.net
>
> for apt-get for RPM for various Red Hat versions, including 9.  I use it
> myself; particularly useful when you need a third-party app that has tons of
>
> dependencies (such as the ALSA drivers, mplayer, and xine).  'apt-get install
>
> xine' (once apt knows from where you want to pull the packages; already set
> up if you download freshrpms' version of apt-get for RPM) and all the
> dependencies are automatically resolved (and installed, after your
> confirmation).

Very nice- wish I would have known about that for this last Progress install.  I
 finally found the one .so I needed with rpm-finder (I think thats the site).  I
used the rpm2tgz converter on Slackware to pull out the file and things worked
find.  Thats my ignorance of the whole rpm thing as well as (IMHO) the Progress
NOT be a big Linux supporter.

> For a GUI to apt, get synaptic (once you have apt4rpm on your
>
> box, apt-get install synaptic), and you will be amazed.
>
> And the two line incantation:
>
> apt-get update
> apt-get upgrade
>
> keeps my system supplied with necessary security errata.
> --
> Lamar Owen
> WGCR Internet Radio
> 1 Peter 4:11
>

Well this email is going my saved-messages.  Thanks for the "class" Lamar.

--
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 Tuesday 15 April 2003 16:03, Network Administrator wrote:
> Quoting Lamar Owen <lamar.owen@wgcr.org>:
> > that matter)) upgrade path -- virtually all other daemons are capable of
> > reading the old configs and data files or there is some form of data
> > migration tool packaged that does not require the old version to use.

> Ahhhh, ok.  I see what you're saying.  I guess the way I look at that is
> that you have the OS and then you have the stuff that runs on the OS.

PostgreSQL, as packaged i Red Hat Linux (since version 5.0) is considered part
of the OS.  For Red Hat.  YMMV, YOMV, etc.

> Ok, I what you're saying here.  I must have mis-read the original email
> 'cause I thought this a PostgreSQL upgrade not a migration from MySQL

No, I was using the MySQL upgrade process as a contrasting example to the way
we do it.  The upgrade in question was PostgreSQL to PostgreSQL of different
major versions.

For a from-source Linux distribution with interesting dependency resolution,
check out Gentoo.  You build your entire dist from source.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

How much different *IS* one distro from another?

Network Administrator wrote:
> 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 it
>>
>>much.
>>
>>>Seems to me you should **always** be able to compile software.
>>>
>>>-$0.02
>>>
>>
>>
>>---------------------------(end of broadcast)---------------------------
>>TIP 6: Have you searched our list archives?
>>
>>http://archives.postgresql.org
>>
>
>
>

> I heard that the debian rev system is MUCH better, but never got accepted
> because of the market weight of RH. Is this so?

Yes and no.  RH and Deb each have their strong points.  I use RH because
they make my life a lot easier (dealing with dselect is an absolute pain,
plus RH's hardware detection is great).

The real problem is - what _should_ they do when you upgrade.  Well,
theoretically, they should do the dump/reload for you.  What if you don't
have enough hard drive space?  What if it fails somewhere?  An automated
install really can't deal with these questions adequately using any
packaging system.



>
> 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.
> >
> > -$0.02
> >
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>

Absolutely.
Do a pg_dumpall before any version upgrade.

My point was that RH has screwed up many software packages lately by
switching to the new NPTL version of glibc. Not only is it in RH 9, but
they also replaced the libraries in RH 8.0. They recently patched the
new glibc and broke more things...

At least FreeBSD accepts patches, and implements them giving the
submitter credit withing a short time. I recently patched the
radiusd-cistron port to fix some problems that would cause core dumps,
and tidied up some uninitialized variables.

If the problem was just failure to backup the databases before
installing a new version of PG then, that is nobodies failt but the
administrator. Reading errata, and other standards docs before install
one would discover they needed to dump and delete before the upgrade
then restore the data afterwards.

The RH issues I was rerferenceing came with *NO* warnings that all sorts
of things would imminently be broken.

I am tired of people sticking up for RH's failure to do proper QA tests,
and there closed opensource ideas.


Guy

Lamar Owen wrote:

>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.
>
>

On Tue, 15 Apr 2003 15:21:36 -0700 Dennis Gearon <gearond@cvc.net> wrote:

> How much different *IS* one distro from another?

the installation, boot time initializations, and packaging systems can be
pretty different, as can the degree of support you get after the fact.

i'm pondering a startup right now which will have some rather stringent
requirements for high availability, and one of the issues that's on my mind
is how to upgrade a high availability postgresql server farm. does anyone
have any thoughts/experience on this?

how are folks implementing high availability setups with postgresql? my db
guy is an old line informix type, and while he likes postgresql a lot, he's
very uncertain how to tackle the high availability issues with the pieces
currently on the table.

richard
--
Richard Welty                                         rwelty@averillpark.net
Averill Park Networking                                         518-573-7592
              Unix, Linux, IP Network Engineering, Security

On Tuesday 15 April 2003 18:26, Guy Fraser wrote:
> My point was that RH has screwed up many software packages lately by
> switching to the new NPTL version of glibc. Not only is it in RH 9, but
> they also replaced the libraries in RH 8.0. They recently patched the
> new glibc and broke more things...

[taken off-list]
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

On Tue, 15 Apr 2003, Lamar Owen wrote:

> On Tuesday 15 April 2003 15:18, Network Administrator wrote:
> > 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...
>
> Ghost can reimage to a drive with a different size and geometry.  It then
> touches up the partition tables, but leaves your bootloader in the MBR
> intact.  I haven't been able to do that with dd as yet; for identical
> geometries dd works well.  I don't have ghost 2003; 2002 couldn't resize
> ext2/3 partitions as yet.  2002 can resize NTFS and FAT, however.
>
> I have used Ghost more than once for hard drive upgrades; both Linux and
> Win2k, desktop and server.
> --
> Lamar Owen
> WGCR Internet Radio
> 1 Peter 4:11

Yep that is the failing of using dd alone and I actually was trying
out some things in a lab setting with sfdisk to try and manually
resize the partition but I didn't get to much into it.  The fact that
I could image our Netware servers with this solution made everyone
happy enough.  But I might try it again 'cause we have used the dd
method to build new servers.  In NT and Netware, you can add space to
your partitions so even though it is not the cleanest approach it did
satisfy the disaster recovery objectives.  I think I might give  it
another shot next time I upgrades the CD.

---
Keith C. Perry
Director of Networks & Applications
Visions Communications Support Network, Inc.
netadmin@vcsn.com
http://vcsn.com
---

On Tue, Apr 15, 2003 at 06:43:48PM -0400, Richard Welty wrote:
> i'm pondering a startup right now which will have some rather stringent
> requirements for high availability, and one of the issues that's on my mind
> is how to upgrade a high availability postgresql server farm. does anyone
> have any thoughts/experience on this?

Define "high availability".

The first thing you need is an OS and hardware that can support hot
plugging of all the hardware, &c.  Plus you need ultra-reliable
hardware in the first place.

Then, use one of the replication systems on offer to make sure
you have a second (and probably third) database.

If you want automated failover, PostgreSQL, Inc. say they'll sell you
something which can do it.  I am suspicious of the assumptions behind
the approach, but I haven;t investigated it deeply.

If what you want is 100% guaranteed uptime with no interruptions for
maintenance, I don't really think Postgres can do it yet.

A

--
----
Andrew Sullivan                         204-4141 Yonge Street
Liberty RMS                           Toronto, Ontario Canada
<andrew@libertyrms.info>                              M2P 2A8
                                         +1 416 646 3304 x110

> If you want automated failover, PostgreSQL, Inc. say they'll sell you
> something which can do it.  I am suspicious of the assumptions behind
> the approach, but I haven;t investigated it deeply.
>
> If what you want is 100% guaranteed uptime with no interruptions for
> maintenance, I don't really think Postgres can do it yet.

I don't think anyone can do this yet.  Some may advertise it, but the
reality usually is different from the advertisements.  Some may be better,
or even much better than Postgres, but even when I worked at EDS, we had
to take down our production databases for very large web sites to do
certain maintenance tasks.

In fact, there, the most usual way of having a nonstop DB was just running
a DB on ultra-reliable hardware.  All of the CPUs were used CPUs that had
never shown any faults - same with memory.

Jon

>
> A
>
> --
> ----
> Andrew Sullivan                         204-4141 Yonge Street
> Liberty RMS                           Toronto, Ontario Canada
> <andrew@libertyrms.info>                              M2P 2A8
>                                          +1 416 646 3304 x110
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
>

Dennis Gearon <gearond@cvc.net> writes:

> 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.

I have had very good luck with partimage for partition copying under
Linux.  I use it to image Linux and Windows 2000 boxes and it works
great.

http://www.partimage.org/

In a pinch I have been known to use dd as well, but I would recommend
it :).

Jason

> So I'm stuck.  Can I get two things, please?

The easiest way is to grab your data directory. If you installed from
RPMS I believe it is in /var/lib/pgsql/data but you will probably want
to double check.

>  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.

Well this is a RedHat foobar. In reality, Red Hat should have a check
to see if a previous version of PostgreSQL is installed via RPM and if
so, don't install the new version. At a minimum they should warn you.

On the other side, an initdb is always required for a major release
(e.g. 7.2 -> 7.3). This is because major releases typically contain
changes to the very lower levels of the database.

Anyway, to get out of this pickle, you need to remove 7.3, get
PostgreSQL 7.2.4 running, with your old data directory (providing you
are running a 7.2 version of PostgreSQL), then run a pg_dumpall, make
at least 4 copies (;)), remove 7.2.4, install 7.3.2, and run a
pg_restore.

Sincerely,
Joshua D. Drake
Command Prompt, Inc.
Co-Author Practical PostgreSQL

P.S. Never upgrade an OS without knowning the dependancies. PostgreSQL
isn't MS Access. It is more like Oracle or (don't flame me) MS SQL.
You can't just "upgrade" it.


>
> 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

On Sunday 20 April 2003 13:05, Joshua Drake wrote:
> Well this is a RedHat foobar. In reality, Red Hat should have a check
> to see if a previous version of PostgreSQL is installed via RPM and if
> so, don't install the new version. At a minimum they should warn you.

The RPM dependencies are set to conflict with previous versions for the
postgresql-server package.  Unfortunately, the version of RPM shipped with
RHL9 doesn't honor a Conflicts against the same package.... :-(  I _know_ my
RPMset has that header set.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

> Yes and no. I will probably draw flames for this but I have successfully
> upgraded MySQL databases between versions (and platforms) without any

Yes but again your comparing Microsoft Access err MySQL to PostgreSQL.
MySQL is not PostgreSQL, literally. It can't do what PostgreSQL does.
I could be incorrect but I don't believe you can just upgrade from say
Oracle 8 to version 9.

Now if I am wrong in that, then we have a problem and it is definately
something that should be addressed.

Sincerely,

Joshua Drake

P.S. My point is, I don't consider MySQL competition. I consider
Oracle competition.


> dumping and that has worked just fine. Like it or not, this has helped its
> adoption immensely, and I think that reducing the need for dumping even
> between major versions (i.e. only when necessary) would be a very welcome
> feature, probably just even from a code maintenance POV.
> PostgreSQL is wicked cool for what it does and has come a long way
> recently, but with 7.4 the impending arrival of hordes of Windows users
> will make ease of use a much more important factor for its broadened
> acceptance - otherwise people _will_ just revert to MySQL and work around
> any problems, as usual.
>
> Otherwise I agree, pgsql is a good replacement for many Oracle or MSSQL
> installations. :)
>
> regards
> Holger