Thread: Debian experimental packages of PostgreSQL 7.4beta4
Debian packages of PostgreSQL 7.4beta4 are available in the experimental section of the Debian archive. -- Oliver Elphick Oliver.Elphick@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
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
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 Oliver.Elphick@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
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
<andrew@libertyrms.info> M2P 2A8
+1 416 646 3304 x110
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 Oliver.Elphick@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
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 <kleptog@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
Attachment
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
<andrew@libertyrms.info> M2P 2A8
+1 416 646 3304 x110
Oops! nandrews@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.
On Friday 10 October 2003 08:52 pm, Christopher Browne wrote:
> Oops! nandrews@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.
I've been watching this discussion with interest (well, I _am_ the RPM
maintainer, after all) and have to say that it has been thought of before.
It wasn't at that time implemented due to political factors (read: the then
Red Hat maintainer (@redhat.com) refused to include such support even if I
had built it). But I did go through the design phase. If everyone can be
patient, I'll try to go back into my archives and dig out the design doc I
put together way back then. In the meantime, I'd like to hear people's
ideas. As alternatives (debian-style) are fully supported in later Red Hat
(and the new Fedora Core) releases, a scheme that uses alternatives would be
ok.
Be sure to post to the pgsql-ports list instead of pgsql-general, though. If
the list server will accept it, reply-to has been set to pgsql-ports.
--
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC 28772
(828)862-5554
www.pari.edu