On Wed, 2007-06-06 at 10:51 +0100, Richard Huxton wrote: > Hannes Dorbath wrote: > > Running 2 PG instances is a trivial thing to do. It requires a quick > > look at the PostgreSQL documentation to find out that: > > > But instead people spend their time on going out and ask how to use some > > poor wrappers, their distribution provides. Probably this has costed > > them more time than a look in the PG documentation. > > I think the point of the Debian (and hence ubuntu) wrappers is to let > the *packaging system* install and run two or more concurrent > installations. Otherwise there's no way to upgrade from one edition of > Debian to another and take your databases with you. Indeed, there are major problems for the packaging system because of the need to dump and reload the database on a major upgrade. When I was doing the Debian packaging, my original approach was to try to automate that procedure so that it would happen seamlessly during the package update. This frequently failed. 1. The dump might fail because of some corruption. 2. There might be some incompatibility which stopped the dump uploading to the new version. 3. The DBA might not wish to upgrade yet. 4. A big database might take a long time to transfer; then there might be problems with disk space. 5. There might be multiple databases; only the one on the default port would be dumped and reloaded. If a new package became available, it would automatically be uploaded on a general upgrade unless the sysadmin placed it on hold; but placing it on hold meant that bug-fixing releases didn't get installed either. So you lost either way. If you assume that there are a dedicated sysadmin and a DBA who thoroughly understand everything that is going on and know all the command-line tools (and probably run Gentoo or Slackware and build everything themselves any way!) you can justify leaving it up to them to choose the right command pathnames and the right port numbers and see to it that their users know what to do. However, the majority of users of packaging systems aren't that capable. That's why they are using the packaging system in the first place. (Or perhaps they want to have time to get some paying work done!) Since I wanted to make life easier for users -- and hence for myself as maintainer as well -- I invented the scheme for installing different PG versions in parallel on Debian. Admittedly it adds some complication, but it avoids unexpected upgrade problems and allows for proper testing before an upgraded database is let loose on its end users. The scheme had to allow for having multiple versions of every executable installed simultaneously and it had to provide a means for ordinary users to get to the right database without having to work out what pathnames and port numbers to use and as far as possible without changing the way they were already working. Martin Pitt took over my initial design and simplified it considerably and has made the system work very well. > Now, I find the Debian approach complicated and fiddly, but I suspect > that's because what it's doing is complicated and fiddly. In fact there is no actual difference for the end-user unless more than one version is installed simultaneously (which will normally only happen while upgrade testing is going on) or unless the system is hosting multiple separate databases; in the latter case I imagine that most users are either guided by scripts or confined by an application program to a single database. Any suggestions for improvement? -- Oliver Elphick olly@xxxxxxxxxx Isle of Wight http://www.lfix.co.uk/oliver GPG: 1024D/A54310EA 92C8 39E7 280E 3631 3F0E 1EC0 5664 7A2F A543 10EA ======================================== Do you want to know God? http://www.lfix.co.uk/knowing_god.html
