FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > CentOS > CentOS Development

 
 
LinkBack Thread Tools
 
Old 01-23-2009, 12:26 AM
John Summerfield
 
Default Upgrading postgresql ( CentOS/RHEL 5.3)

Jeff Johnson wrote:
>
> On Jan 22, 2009, at 4:40 PM, Les Mikesell wrote:
>>
>> Agreed, it doesn't work. Nor does any other RPM-managed update where
>> you need to have both old and new packages simultaneously working for a
>> while. The special case for the kernel is about the only place where it
>> even attempts to keep old versions around for an emergency fallback.
>>
>
> Honking about RPM deficiencies on a CentOS Devel list is hot air going
> no place.
>
> FWIW, there's no package system that provides sufficient facilties to
> undertake
> a postgres upgrade reliably during upgrade that I'm aware of. Nor is it
> "recommended" afaik.

I thought that point was already conceded.

However, there is nothing now that prevents two versions of postgresql
from being built with version-dependent directory names (as it almost is):
[root@numbat ~]# rpm -qvl postgresql | grep ^d
drwxr-xr-x 2 root root 0 Jan 12 2008 /usr/lib/pgsql
drwxr-xr-x 2 root root 0 Jan 12 2008
/usr/share/doc/postgresql-8.1.11
drwxr-xr-x 2 root root 0 Jan 12 2008
/usr/share/doc/postgresql-8.1.11/html
[root@numbat ~]#
Change that to /usr/lib/pgsql-8.1.11, create a bin directory in there
and use the alternatives system to choose the default.

The configuration and data directory names need to be changed too.


>
> But supply a pointer to your favorite package manager that _DOES_ attempt
> postgres database upgrades and I'll be happy to attempt equivalent in RPM.
>
> Personally, I think that database upgrades have almost nothing
> to do with instaling packages, but I'd rather add whatever is useful
> than discuss well known RPM deficiencies for another decade.

In-package (or upgrade-time) configuration conversion will always fail
for some packages, but I see no reason that users shouldn't be able to
run old and new versions of (at least) _some_ packages simultaneously.
It would make upgrades easier for sysadmins with just a few systems to
maintain - depending on needs they could upgrade a clone and test it and
fix and document broken bits without having to start from scratch each time.

--

Cheers
John

-- spambait
1aaaaaaa@coco.merseine.nu Z1aaaaaaa@coco.merseine.nu
-- Advice
http://webfoot.com/advice/email.top.php
http://www.catb.org/~esr/faqs/smart-questions.html
http://support.microsoft.com/kb/555375

You cannot reply off-list:-)
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 01-23-2009, 05:42 AM
Hugo van der Kooij
 
Default Upgrading postgresql ( CentOS/RHEL 5.3)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Joshua Kramer wrote:
>> I consider that a major upstream bug.
>> Better would be for postgresql to ship a standalone SQL dumper, which can
>> read old file formats.
>
> Charlie,
>
> Would you expect a "simple" upgrade of Oracle 10i to Oracle 11, for your
> major enterprise application? Or, MS-SQL 2005 to MS-SQL 2008?

You windows users: Yes, they woukd

Hugo

- --
hvdkooij@vanderkooij.org http://hugo.vanderkooij.org/
PGP/GPG? Use: http://hugo.vanderkooij.org/0x58F19981.asc

A: Yes.
>Q: Are you sure?
>>A: Because it reverses the logical flow of conversation.
>>>Q: Why is top posting frowned upon?

Bored? Click on http://spamornot.org/ and rate those images.

Nid wyf yn y swyddfa ar hyn o bryd. Anfonwch unrhyw waith i'w gyfieithu.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkl5ZsYACgkQBvzDRVjxmYHEJACgmrswA3IrMu k+sfXFRbXBLp4q
FwcAnRuCTEVjNGudUkHb3dm6MruEtuyf
=uo1q
-----END PGP SIGNATURE-----
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 01-23-2009, 12:28 PM
Jeff Johnson
 
Default Upgrading postgresql ( CentOS/RHEL 5.3)

On Jan 23, 2009, at 1:42 AM, Hugo van der Kooij wrote:


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Joshua Kramer wrote:

I consider that a major upstream bug.
Better would be for postgresql to ship a standalone SQL dumper,
which can

read old file formats.


Charlie,

Would you expect a "simple" upgrade of Oracle 10i to Oracle 11, for
your

major enterprise application? Or, MS-SQL 2005 to MS-SQL 2008?


You windows users: Yes, they woukd



Actually, its "commercial" vs "FLOSS" for the database that is the
distinguishing attribute determining whether upgrades are simple
in the above.

Most FLOSS databases, like postgres, are harder to upgrade than
"commercial" databases like Oracle.

73 de Jeff______________________________________________ _
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 01-23-2009, 02:38 PM
Charlie Brady
 
Default Upgrading postgresql ( CentOS/RHEL 5.3)

On Fri, 23 Jan 2009, Jeff Johnson wrote:

> On Jan 23, 2009, at 1:42 AM, Hugo van der Kooij wrote:
>
>> > Would you expect a "simple" upgrade of Oracle 10i to Oracle 11, for your
>> > major enterprise application? Or, MS-SQL 2005 to MS-SQL 2008?
>>
>> You windows users: Yes, they woukd
>
> Actually, its "commercial" vs "FLOSS" for the database that is the
> distinguishing attribute determining whether upgrades are simple
> in the above.
>
> Most FLOSS databases, like postgres, are harder to upgrade than
> "commercial" databases like Oracle.

And it will remain that way, until FLOSS developers consider it legitimate
to wonder why it is that way, and consider how to improve the situation.

>From my point of view, what's egregious with packaged postgresql is that
it allows you to "upgrade" a postgresql installation to a state where the
data is no longer accessable. At the least, one should be able to dump the
data to SQL after upgrade.

There's been much discussion about what rpm can and cannot do. One thing
rpm can do, however, is to run a pre-script which uses the files of a a
previously installed version. A pre script could detect an upgrade from
the old version which uses an incompatible backend format, and could
then create the SQL dump (starting postmaster and waiting for it if
required).

I don't buy the arguments that changes in the supported SQL language make
automated upgrades of the backend data impossible. Dump, upgrade,
re-import couldn't work if that were the case.

Thanks (over and out).

---
Charlie
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 01-23-2009, 09:57 PM
Les Mikesell
 
Default Upgrading postgresql ( CentOS/RHEL 5.3)

Charlie Brady wrote:
>
>>From my point of view, what's egregious with packaged postgresql is that
> it allows you to "upgrade" a postgresql installation to a state where the
> data is no longer accessable. At the least, one should be able to dump the
> data to SQL after upgrade.
>
> There's been much discussion about what rpm can and cannot do. One thing
> rpm can do, however, is to run a pre-script which uses the files of a a
> previously installed version. A pre script could detect an upgrade from
> the old version which uses an incompatible backend format, and could
> then create the SQL dump (starting postmaster and waiting for it if
> required).

Maybe. What happens if you run out of space? Or have to choose
available space from different partitions or network mounts? Or you
don't have the space for the reload in the new format? These are all
likely scenarios for database machines.

> I don't buy the arguments that changes in the supported SQL language make
> automated upgrades of the backend data impossible. Dump, upgrade,
> re-import couldn't work if that were the case.

They may work, but you can't assume that the applications will work
unchanged on the new version, or that the applications are all part of
the same upgrade. For example, anything that relied on the implict
casts that were removed between 8.2 and 8.3 won't work, so you'll need
to convert back when you find that out. This doesn't mean the
conversion can't be automated, just that the operator may need to make a
few choices along the way, including when it is safe to remove the old
version.

--
Les Mikesell
lesmikesell@gmail.com


_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 02-10-2009, 12:46 PM
John Summerfield
 
Default Upgrading postgresql ( CentOS/RHEL 5.3)

Joshua Kramer wrote:
>> I consider that a major upstream bug.
>> Better would be for postgresql to ship a standalone SQL dumper, which can
>> read old file formats.
>
> Charlie,
>
> Would you expect a "simple" upgrade of Oracle 10i to Oracle 11, for your
> major enterprise application? Or, MS-SQL 2005 to MS-SQL 2008?
>
> Any major database version upgrade requires the attention of a qualified
> DBA who knows how to test data and applications against the new DB
> version, and then dump/upgrade/restore.

I used to work for SPL (Australia), in the early 80s. We were the
Australian agent for Software AG, and sold and supported ADABAS and
related software in Australian (and I think) NZ.

When our clients upgraded from 3.2.x to 4.1.x the index structures
changed (as you might expect, with improved algorithms and maybe
increased capacity), but the data on disk was unaffected. In principle,
going back or forward required no more than rebuilding indexes (and, of
course, the attendant maintenance procedures etc).



>
> For example, PostgreSQL introduced some minor syntactical differences with
> 8.3. If your application uses the features affected by these changes, it
> would be impossible to simply 'dump/restore' without some massaging of the
> data and the application.
>
> PostgreSQL does ship with a dumper, pg_dump. If you have the current

The previous writer said "stand alone." That is not.





--

Cheers
John

-- spambait
1aaaaaaa@coco.merseine.nu Z1aaaaaaa@coco.merseine.nu
-- Advice
http://webfoot.com/advice/email.top.php
http://www.catb.org/~esr/faqs/smart-questions.html
http://support.microsoft.com/kb/555375

You cannot reply off-list:-)
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 

Thread Tools




All times are GMT. The time now is 05:04 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org