Thread: Re: Redhat 7 and PgSQL
I downloaded the RedHat 7 ISO images and the PostgresqL 7.0.2 RPMS were on the CDs. Dale. >>> "Alfredo" <csib@mweb.com.na> 09/29/00 12:28PM >>> I heard that MySQL is included in RH 7 instead of PgSQL. Is this true? if yes, anybody know why? Regards Thanks
> >>> "Alfredo" <csib@mweb.com.na> 09/29/00 12:28PM >>> > I heard that MySQL is included in RH 7 instead of PgSQL. Is this true? if > yes, anybody know why? i think the thing is that they added mysql because it's now GPL'd -- it wasn't in there before because it wasn't really "free" software. postgres (7.0.2) is indeed still in redhat 7, but with some of the comments on the list about the RPMs, it's possible that it may not stay as part of the distribution because of upgrading issues. -- Jeff Hoffmann PropertyKey.com
Jeff Hoffmann <jeff@propertykey.com> writes: > > >>> "Alfredo" <csib@mweb.com.na> 09/29/00 12:28PM >>> > > I heard that MySQL is included in RH 7 instead of PgSQL. Is this true? if > > yes, anybody know why? > > i think the thing is that they added mysql because it's now GPL'd -- it > wasn't in there before because it wasn't really "free" software. > postgres (7.0.2) is indeed still in redhat 7, but with some of the > comments on the list about the RPMs, it's possible that it may not stay > as part of the distribution because of upgrading issues. I've never said or indicated that. That said, I dislike the current no-upgrade policy. -- Trond Eivind Glomsrød Red Hat, Inc.
Forgive my ignorance. What is this no-upgrade policy issue about? Jeff Hoffmann <jeff@propertykey.com> writes: > > >>> "Alfredo" <csib@mweb.com.na> 09/29/00 12:28PM >>> > > I heard that MySQL is included in RH 7 instead of PgSQL. Is this true? if > > yes, anybody know why? > > i think the thing is that they added mysql because it's now GPL'd -- it > wasn't in there before because it wasn't really "free" software. > postgres (7.0.2) is indeed still in redhat 7, but with some of the > comments on the list about the RPMs, it's possible that it may not stay > as part of the distribution because of upgrading issues. I've never said or indicated that. That said, I dislike the current no-upgrade policy. -- Trond Eivind Glomsrød Red Hat, Inc.
"Efrain Caro" <betsemes@hotmail.com> writes: > Forgive my ignorance. What is this no-upgrade policy issue about? That you can't upgrade postgresql from e.g. 6.5 to 7.0 or from 7.0 to 7.1 Incidentally, you can dump data from a database. You can also insert data into a database. If you do this before and after upgrading, you'll hopefully have the same data in the database. -- Trond Eivind Glomsrød Red Hat, Inc.
On 29 Sep 2000, Trond Eivind Glomsrød wrote:
> That you can't upgrade postgresql from e.g. 6.5 to 7.0 or from 7.0 to
> 7.1
>
> Incidentally, you can dump data from a database. You can also insert
> data into a database. If you do this before and after upgrading,
> you'll hopefully have the same data in the database.
FWIW, that's pretty tame compared to trying to migrate and upgrade an
Oracle database. Have you ever seen some of the upgrade path rules for
Oracle? If it's this version, first migrate to this version and then
upgrade, but if it's this other version, then it can upgrade directly,
unless it's the beta version, then you have to migrate blah blah blah...
Is it feasible to create a 'universal installer' for PostgreSQL similar to
what Oracle has (especially for binary distributions) that will do the
data migration behind the scenes? Doing the source compile will probably
require migrating the stuff manually (but if you are installing from
source, you are doing everything manually *anyway*).
Brett W. McCoy
http://www.chapelperilous.net
---------------------------------------------------------------------------
WHO sees a BEACH BUNNY sobbing on a SHAG RUG?!
"Efrain Caro" <betsemes@hotmail.com> writes:
> Forgive my ignorance. What is this no-upgrade policy issue about?
It's not a "policy", it's just a problem: you usually can't update to
a new major Postgres release without doing dump/initdb/reload.
regards, tom lane
So we can say that we can upgrade, at least in theory, but that's not the
official policy?
----- Original Message -----
From: <bmccoy@chapelperilous.net>
To: "Trond Eivind Glomsrød" <teg@redhat.com>
Cc: "Efrain Caro" <betsemes@hotmail.com>; "Jeff Hoffmann"
<jeff@propertykey.com>; <pgsql-general@postgresql.org>
Sent: Friday, September 29, 2000 11:36 AM
Subject: Re: [GENERAL] Redhat 7 and PgSQL
On 29 Sep 2000, Trond Eivind Glomsrød wrote:
> That you can't upgrade postgresql from e.g. 6.5 to 7.0 or from 7.0 to
> 7.1
>
> Incidentally, you can dump data from a database. You can also insert
> data into a database. If you do this before and after upgrading,
> you'll hopefully have the same data in the database.
FWIW, that's pretty tame compared to trying to migrate and upgrade an
Oracle database. Have you ever seen some of the upgrade path rules for
Oracle? If it's this version, first migrate to this version and then
upgrade, but if it's this other version, then it can upgrade directly,
unless it's the beta version, then you have to migrate blah blah blah...
Is it feasible to create a 'universal installer' for PostgreSQL similar to
what Oracle has (especially for binary distributions) that will do the
data migration behind the scenes? Doing the source compile will probably
require migrating the stuff manually (but if you are installing from
source, you are doing everything manually *anyway*).
Brett W. McCoy
http://www.chapelperilous.net
---------------------------------------------------------------------------
WHO sees a BEACH BUNNY sobbing on a SHAG RUG?!
On Fri, 29 Sep 2000, Efrain Caro wrote:
> So we can say that we can upgrade, at least in theory, but that's not the
> official policy?
Well, I don't know about 'policy', but yes, you can upgrade PostgreSQL,
you just need to dump your data first (which you should do anyway to
backup -- never upgrade without backing up first!), install the upgrade by
whatever method, do the initdb, then reload your data. It's a minor PITA,
but it's also safe -- if you are doing a direct upgrade and it crashes or
something else really bad happens, your database could get severely
screwed. And then you're screwed.
Brett W. McCoy
http://www.chapelperilous.net
---------------------------------------------------------------------------
Hoare's Law of Large Problems:
Inside every large problem is a small problem struggling to get out.
Well, I treat upgrading RedHat like I treat upgrading any OS... clean install. Adam Lang Systems Engineer Rutgers Casualty Insurance Company ----- Original Message ----- From: "Jeff Hoffmann" <jeff@propertykey.com> Cc: <pgsql-general@postgresql.org> Sent: Friday, September 29, 2000 10:45 AM Subject: Re: [GENERAL] Redhat 7 and PgSQL > > >>> "Alfredo" <csib@mweb.com.na> 09/29/00 12:28PM >>> > > I heard that MySQL is included in RH 7 instead of PgSQL. Is this true? if > > yes, anybody know why? > > i think the thing is that they added mysql because it's now GPL'd -- it > wasn't in there before because it wasn't really "free" software. > postgres (7.0.2) is indeed still in redhat 7, but with some of the > comments on the list about the RPMs, it's possible that it may not stay > as part of the distribution because of upgrading issues. > > -- > > Jeff Hoffmann > PropertyKey.com
Tom Lane wrote: > > "Efrain Caro" <betsemes@hotmail.com> writes: > > Forgive my ignorance. What is this no-upgrade policy issue about? > > It's not a "policy", it's just a problem: you usually can't update to > a new major Postgres release without doing dump/initdb/reload. The 'policy' is the lack of assigning developer time to fixing the problem. Smooth upgrades could easily be sold as a major feature. IMHO. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Trond Eivind Glomsrød writes: > Incidentally, you can dump data from a database. You can also insert > data into a database. If you do this before and after upgrading, > you'll hopefully have the same data in the database. If there's a problem with pg_dump then pg_dump needs to be fixed, and incidentally, Philip Warner has been doing just that. But claiming that you can't upgrade is painting over what might rather be a deficiency in the RPM mechanism, ISTM. Why can't you have a spec file like this: %preupgrade pg_dumpall >somewhere %postupgrade ... psql -f somewhere -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
Peter Eisentraut <peter_e@gmx.net> writes: > But claiming that you can't upgrade is painting over what might rather be > a deficiency in the RPM mechanism, ISTM. Why can't you have a spec file > like this: > > %preupgrade > pg_dumpall >somewhere 1) You don't know that postgresql is running. It probably isn't. 2) You don't know that you have the diskspace to do that. -- Trond Eivind Glomsrød Red Hat, Inc.
On 29 Sep 2000, Trond Eivind Glomsrød wrote:
> > But claiming that you can't upgrade is painting over what might rather be
> > a deficiency in the RPM mechanism, ISTM. Why can't you have a spec file
> > like this:
> >
> > %preupgrade
> > pg_dumpall >somewhere
>
>
> 1) You don't know that postgresql is running. It probably isn't.
> 2) You don't know that you have the diskspace to do that.
These are things that have to be considered regardless of the upgrade
mechanism.
Brett W. McCoy
http://www.chapelperilous.net
---------------------------------------------------------------------------
What no spouse of a writer can ever understand is that a writer is working
when he's staring out the window.
Trond Eivind Glomsrød wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
> > But claiming that you can't upgrade is painting over what might rather be
> > a deficiency in the RPM mechanism, ISTM. Why can't you have a spec file
> > like this:
> > %preupgrade
> > pg_dumpall >somewhere
> 1) You don't know that postgresql is running. It probably isn't.
> 2) You don't know that you have the diskspace to do that.
3.) If you are running inside the Red Hat OS installer (which the
PostgreSQL RPM's currently _do_), you can't start a postmaster. You
can't ask the user anything. You can't tell the user anything. And a
postmaster is guaranteed NOT to be running. Oh, and you can't test to
see if you are being upgraded inside the installer or from the command
line, thanks to some other restrictions due to the special chroot()
environment of the installer :-).
So, the current strategy is:
1.) If this is an upgrade, backup the old postgres, postmaster,
libpq.so, pg_dump, and psql, and copy to a known place with a new
pg_dumpall.
2.) Upgrade (which means install the new, then delete anything that was
old that didn't get overwritten by the new).
3.) If the user tries to start a postmaster using the supplied script,
check the data tree:
a.) if there is nothing, initdb it;
b.) if there is a compatible version's tree, start postmaster;
c.) if there is an incompatible version's tree, print an error and
punt.
4.) If a data upgrade is necessary, then:
a.) perform a dump of the old database using the executables saved
above, using a special script that set all sorts of oddball options to
get the old to run;
b.) make a binary copy of the old data, just in case;
c.) whop the old tree into oblivion;
d.) start the new postmaster using the supplied script (which does you
initdb with all the right options for Red Hat);
c.) restore your data.
Step 4 is manual, with the only assist being the performance of the
dump. This process does not work well. Oliver Elphick I know has
similar problems with the Debian package upgrading, although Debian
allows its packages to interact on upgrades. The script used in the
RPM's is a modified copy of Oliver's Debian script, although RH7
includes another script that shold be used for RH7, due to some changes
made in the PostgreSQL 7 RPMset that made the postgresql-dump script die
a horrible screaming death.
Now, the way RPM's upgrade is designed into the RPM package system --
and the MySQL RPM's don't have these problems with the system. RPM is
designed to do unattended mass upgrading -- and it is the responsibility
of both the sysadmin doing the upgrade and the packager to make sure no
one gets hosed in the process. The semi-automatic method used is a
compromise, for sure -- but, it is better than alternatives.
Now, there are some problems with pg_dump, at least on one datamodel I
know of. We on that team are working up a detailed bug report for your
viewing pleasure for posting at a later date.
And MANY THANKS AND KUDOS to Philip Warner for adopting pg_dump and
kin!!! Hopefully the new pg_dump will clear some things up. Being able
to deal with large objects for the first time will be a lifesaver for
many.
Opinion seems to be pretty evenly split right now about seamless
upgrading -- of course, this is one program that absolutely MUST be
right.
Alot of people will be made very happy when this problem is solved.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
On Fri, 29 Sep 2000, Jeff Hoffmann wrote: > > >>> "Alfredo" <csib@mweb.com.na> 09/29/00 12:28PM >>> > > I heard that MySQL is included in RH 7 instead of PgSQL. Is this true? if > > yes, anybody know why? > > i think the thing is that they added mysql because it's now GPL'd -- it > wasn't in there before because it wasn't really "free" software. > postgres (7.0.2) is indeed still in redhat 7, but with some of the > comments on the list about the RPMs, it's possible that it may not stay > as part of the distribution because of upgrading issues. I upgraded a 6.x postgres database server to a 7.0.2 with little suffering. It could be done with a script very easilly. "And I'm happy, because you make me feel good, about me." - Melvin Udall ----------------------------------------------------------------- Martín Marqués email: martin@math.unl.edu.ar Santa Fe - Argentina http://math.unl.edu.ar/~martin/ Administrador de sistemas en math.unl.edu.ar -----------------------------------------------------------------
On Fri, 29 Sep 2000, Adam Lang wrote: > Well, I treat upgrading RedHat like I treat upgrading any OS... clean > install. This was one of the smartest things I heard today. Any way, what are backups for? ;-) "And I'm happy, because you make me feel good, about me." - Melvin Udall ----------------------------------------------------------------- Martín Marqués email: martin@math.unl.edu.ar Santa Fe - Argentina http://math.unl.edu.ar/~martin/ Administrador de sistemas en math.unl.edu.ar -----------------------------------------------------------------
Trond Eivind Glomsrød writes: > > %preupgrade > > pg_dumpall >somewhere > 1) You don't know that postgresql is running. It probably isn't. Then start it. > 2) You don't know that you have the diskspace to do that. Changing from one storage format to another always requires 2x space (although a text dump is usually smaller than the internal representation). And you're not going to get the storage format to not ever change again. :-) -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
Peter Eisentraut <peter_e@gmx.net> writes: > Trond Eivind Glomsrød writes: > > > > %preupgrade > > > pg_dumpall >somewhere > > > 1) You don't know that postgresql is running. It probably isn't. > > Then start it. That may not be possible, and wouldn't handle the possibility of it not starting. > > 2) You don't know that you have the diskspace to do that. > > Changing from one storage format to another always requires 2x space > (although a text dump is usually smaller than the internal > representation). That depends on how you manipulate the on-disk format, but right now, a problem is you have to do this before upgrading. Having a separate tool going from one on-disk format to another and possibly failing because of lack of disk space is OK - as long you can run it later when you've added more space or point at a place with enough space etc. > And you're not going to get the storage format to not > ever change again. :-) With some thought and design for adding future capabities, perhaps it could be possible? -- Trond Eivind Glomsrød Red Hat, Inc.