By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
437,777 Members | 1,755 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 437,777 IT Pros & Developers. It's quick & easy.

Debian experimental packages of PostgreSQL 7.4beta4

P: n/a
Debian packages of PostgreSQL 7.4beta4 are available in the experimental
section of the Debian archive.

--
Oliver Elphick Ol************@lfix.co.uk
Isle of Wight, UK http://www.lfix.co.uk/oliver
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C
========================================
"He that covereth his sins shall not prosper; but whoso
confesseth and forsaketh them shall have mercy."
Proverbs 28:13
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Nov 12 '05 #1
Share this Question
Share on Google+
7 Replies


P: n/a

On Fri, 10 Oct 2003, Oliver Elphick wrote:
Debian packages of PostgreSQL 7.4beta4 are available in the experimental
section of the Debian archive.


One thing I've been thinking/worrying about recently is the upgrade
process. Rest assured this isn't rehashing the pg_upgrade debate though.

What I'm wondering about is that I'm faced with a production box that is
installed with a Redhat system, that's run by someone else and they do things
'by the book'. That is, software comes in RPM form, possibly RPMS form, but no
way does it come in any other form since it's obviously not supported in that
case. Now, we're coming up to the time when 7.4 is released, should I go to the
extent of porting the db from 7.3 I'll be faced with the situation where the
production db has to be brought down to do the upgrade which even after testing
may fail in the process. Factor into that that I'm sure the people admin-ing
the box probably will not do this during a quiet time, i.e. middle of the
night, I have a problem...unless the RPMs are relocatable.

I've not looked at many RPMs but I must say that the few I have have never been
relocatable. Can the postgresql RPMs not be made relocatable? At least in
that case I could run the two versions concurrently rather than the admins be
forced to shut 7.3 down, uninstall it, install 7.4, start it up and run the
upgrade/load scripts before reenabling the application.

If it were me I'd just use stow like I do on all my systems if only more
software wouldn't assume it knew where it was going to be installed before
configure and build, but that's a whole other gripe.
--
Nigel J. Andrews
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

Nov 12 '05 #2

P: n/a
On Fri, 2003-10-10 at 22:08, Nigel J. Andrews wrote:
On Fri, 10 Oct 2003, Oliver Elphick wrote:
Debian packages of PostgreSQL 7.4beta4 are available in the experimental
section of the Debian archive.


One thing I've been thinking/worrying about recently is the upgrade
process. Rest assured this isn't rehashing the pg_upgrade debate though.

What I'm wondering about is that I'm faced with a production box that is
installed with a Redhat system, that's run by someone else and they do things
'by the book'. That is, software comes in RPM form, possibly RPMS form, but no
way does it come in any other form since it's obviously not supported in that
case. Now, we're coming up to the time when 7.4 is released, should I go to the
extent of porting the db from 7.3 I'll be faced with the situation where the
production db has to be brought down to do the upgrade which even after testing
may fail in the process. Factor into that that I'm sure the people admin-ing
the box probably will not do this during a quiet time, i.e. middle of the
night, I have a problem...unless the RPMs are relocatable.

I've not looked at many RPMs but I must say that the few I have have never been
relocatable. Can the postgresql RPMs not be made relocatable? At least in
that case I could run the two versions concurrently rather than the admins be
forced to shut 7.3 down, uninstall it, install 7.4, start it up and run the
upgrade/load scripts before reenabling the application.


Well, I can't speak for the RPM builders, but I have been thinking about
this issue in respect of the debs.

I am not happy about the current situation for Debian upgrading, which
seems to be pretty fragile. There are a fair number of bug reports from
people for whom the upgrade has barfed in some way or other. The
situation for RPMs is even worse, since the installation scripts are far
more rigidly constrained than are the Debian installation scripts. Of
course, that's why Lamar and I would be so happy to see a working
pg_upgrade tool. But there's no prospect of that in even the medium
term, as far as I can see.

Your suggestion of parallel installations is the solution I have been
considering. If the new package could be installed alongside the old,
there would be no need to upgrade the data during installation and no
danger of data loss.

Another reason for considering this is for the benefit of people who
want to run multiple versions. Perhaps they have an application which
is live and they want to keep that going while they update its code for
use with the new PostgreSQL; it will be much easier for them if the two
versions can be installed side by side as packages. Other users may
have multiple database users, who want to use different software
versions.

For that to work, however, we need a mechanism for assigning a port to
each package and database and for determining which version of the
client software each user will get. So that means that in each package,
psql must be renamed psql-7.3, psql-7.4 and so on. Then psql becomes a
soft link to the default psql version. Debian's alternatives system
(update-alternatives(8)) provides a convenient mechanism for making
those soft links if there is a single systemwide default, but not if
there are different users who want different versions. I don't know if
Red Hat has anything similar.

At the same time, I would like to make the packages cope with multiple
database structures, which are also needed by ISPs and others who need
to charge users for space used.

Assuming multiple versions installed simultaneously, with multiple
data/base structures

DB struct
owner PGDATA Version PGPORT

fred /var/lib/pg/fred 7.3 5433
george /var/lib/pg/george 7.4 5434
harry /var/lib/pg/harry 7.4 5435

then the packages need to provide the means for each user to get the
right PGPORT and the appropriate client software to access that port.

I haven't got any further than this, but I wonder if this is something
that would be useful to the whole project and not just to the
distributions. Any comments?

--
Oliver Elphick Ol************@lfix.co.uk
Isle of Wight, UK http://www.lfix.co.uk/oliver
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C
========================================
"He that covereth his sins shall not prosper; but whoso
confesseth and forsaketh them shall have mercy."
Proverbs 28:13
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

Nov 12 '05 #3

P: n/a
Oops! na******@investsystems.co.uk ("Nigel J. Andrews") was seen spray-painting on a wall:
I've not looked at many RPMs but I must say that the few I have have
never been relocatable. Can the postgresql RPMs not be made
relocatable?


Unfortunately, relocation would have to include the init scripts, and
that would be pretty hairy. The notion of "relocatable RPMs" came up
early in its design, but the only case where that will be particularly
usable is if the components are mostly binaries that only make
relative path references. That situation is unusual, to say the
least.
--
wm(X,Y):-write(X),write('@'),write(Y). wm('aa454','freenet.carleton.ca').
http://www.ntlug.org/~cbbrowne/postgresql.html
MICROS~1 is not the answer.
MICROS~1 is the question.
NO (or Linux) is the answer.
Nov 12 '05 #4

P: n/a
On Fri, Oct 10, 2003 at 11:17:53PM +0100, Oliver Elphick wrote:
I haven't got any further than this, but I wonder if this is something
that would be useful to the whole project and not just to the
distributions. Any comments?


None except that this is more or less how we manage multiple
installations and back ends in our test and production environments.
It works pretty well. I also know that Tom Lane uses something again
similar in order to support the apparently limitless different
permutations of installations he has available at the touch of '.
filename'.

A

--
----
Andrew Sullivan 204-4141 Yonge Street
Afilias Canada Toronto, Ontario Canada
<an****@libertyrms.info> M2P 2A8
+1 416 646 3304 x110
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

Nov 12 '05 #5

P: n/a
On Sun, 2003-10-12 at 00:28, Andrew Sullivan wrote:
On Fri, Oct 10, 2003 at 11:17:53PM +0100, Oliver Elphick wrote:
I haven't got any further than this, but I wonder if this is something
that would be useful to the whole project and not just to the
distributions. Any comments?


None except that this is more or less how we manage multiple
installations and back ends in our test and production environments.
It works pretty well. I also know that Tom Lane uses something again
similar in order to support the apparently limitless different
permutations of installations he has available at the touch of '.
filename'.


I imagine a lot of people have such in-house set-ups. The question is
whether the project itself should provide the structure to do it.

--
Oliver Elphick Ol************@lfix.co.uk
Isle of Wight, UK http://www.lfix.co.uk/oliver
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C
========================================
"Blessed is the man who makes the LORD his trust,
who does not look to the proud, to those who turn
aside to false gods." Psalms 40:4
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org

Nov 12 '05 #6

P: n/a
On Sun, Oct 12, 2003 at 10:21:39AM +0100, Oliver Elphick wrote:
I imagine a lot of people have such in-house set-ups. The question is
whether the project itself should provide the structure to do it.
I'd love to have something like this. It'd be really useful to be able to
install multiple versions simultaneously for testing migrations and such.
The main issue I can see is that if the port number is not predicatable that
connections from other machines won't work as expected any more.

That could be solved by some kind of meta-server but that has other issues.

Good luck
--
Martijn van Oosterhout <kl*****@svana.org> http://svana.org/kleptog/ "All that is needed for the forces of evil to triumph is for enough good
men to do nothing." - Edmond Burke
"The penalty good people pay for not being interested in politics is to be
governed by people worse than themselves." - Plato


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE/iR+WY5Twig3Ge+YRAhW5AJ9pM125Bn1o1+8rWAA+JxYlK7hGPQ CggZnx
RHAgmCALWlNr00Z3LnIWVzE=
=MGde
-----END PGP SIGNATURE-----

Nov 12 '05 #7

P: n/a
On Sun, Oct 12, 2003 at 10:21:39AM +0100, Oliver Elphick wrote:
I imagine a lot of people have such in-house set-ups. The question is
whether the project itself should provide the structure to do it.


Oh, sorry, I intended that to be a note of support. We do use it for
precisely the reasons you mention, and I think it'd be very useful
for packages to offer the same sort of facility. I think it's a
splendid idea.

A

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

Nov 12 '05 #8

This discussion thread is closed

Replies have been disabled for this discussion.