Thread: Running v8.1 amd v8.2 at the same time for a transition
Hi all. I need to run both 8.1 and 8.2 at the same time in order to check everything in 8.2 *before* shutting 8.1 down. I need to run both as I only have one machine available. I'm using a debian derivateive (Kubuntu) that provides a nice pg_wrapper mechanism to direct connections for tools to either version you want. Infact I see both versions running, one on port 5432 and one on port 5433. The point is thay I have no clue on ow to choose which instance attach to. I've already posted this question to the KUbuntu team with no answer in 14+ hours. Is there anyone with a good hint? Thanks. -- Vincenzo Romano -- Maybe Computer will never become as intelligent as Humans. For sure they won't ever become so stupid. [VR-1988]
Vincenzo Romano wrote: > Hi all. > I need to run both 8.1 and 8.2 at the same time in order to check > everything in 8.2 *before* shutting 8.1 down. > I need to run both as I only have one machine available. > I'm using a debian derivateive (Kubuntu) that provides a nice pg_wrapper > mechanism to direct connections for tools to either version you want. > Infact I see both versions running, one on port 5432 and one on port 5433. > The point is thay I have no clue on ow to choose which instance attach to. > I've already posted this question to the KUbuntu team with no answer in 14+ > hours. You choose one or the other by changing the port. If you're not sure which is running on which port, you can try connecting. something along the lines of: psql -p 5433 -U postgres template1 select version(); should tell you.
On Tue, 2007-06-05 at 23:40 +0200, Vincenzo Romano wrote: > Hi all. > I need to run both 8.1 and 8.2 at the same time in order to check > everything in 8.2 *before* shutting 8.1 down. > I need to run both as I only have one machine available. > I'm using a debian derivateive (Kubuntu) that provides a nice pg_wrapper > mechanism to direct connections for tools to either version you want. > Infact I see both versions running, one on port 5432 and one on port 5433. > The point is thay I have no clue on ow to choose which instance attach to. > I've already posted this question to the KUbuntu team with no answer in 14+ > hours. > > Is there anyone with a good hint? man pg_wrapper psql --cluster 8.1/main -d your_database -- Oliver Elphick olly@lfix.co.uk 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
On Tuesday 05 June 2007 23:55:20 Oliver Elphick wrote: > On Tue, 2007-06-05 at 23:40 +0200, Vincenzo Romano wrote: > > Hi all. > > I need to run both 8.1 and 8.2 at the same time in order to check > > everything in 8.2 *before* shutting 8.1 down. > > I need to run both as I only have one machine available. > > I'm using a debian derivateive (Kubuntu) that provides a nice pg_wrapper > > mechanism to direct connections for tools to either version you want. > > Infact I see both versions running, one on port 5432 and one on port > > 5433. The point is thay I have no clue on ow to choose which instance > > attach to. I've already posted this question to the KUbuntu team with no > > answer in 14+ hours. > > > > Is there anyone with a good hint? > > man pg_wrapper > > psql --cluster 8.1/main -d your_database Much better, as I've been told: pg_lsclusters will show all the active clusters. The bad point is that there's a lack of information or, at least, of cross references. The "main" cluster is mentioned only in /usr/share/doc/postgresql-<VER>/README.Debian.gz and not in the manpages. And ther's no cross reference into the pg_wrapper(1), user_clusters(5) or postgresqlrc(5) man pages. But the point is that I'm a newbie so maybe it's just my fault! -- Vincenzo Romano -- Maybe Computer will never become as intelligent as Humans. For sure they won't ever become so stupid. [VR-1988]
On 06.06.2007 09:00, Vincenzo Romano wrote: > (Kubuntu) that provides a nice pg_wrapper > The point is thay I have no clue on ow to choose which instance attach to. Isn't it funny that stupid wrapper scripts create confusion instead of making things easier for users. Running 2 PG instances is a trivial thing to do. It requires a quick look at the PostgreSQL documentation to find out that: - The port is defined in postgresql.conf - pg_ctl -D defines what cluster to work on - The switch for the port in psql is -p 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. Those wrappers often have poor error handling and as they try to hide everything from the user, the user will be unable to fix something once the wrapper fails. Anyway, I guess wrappers are a must have like 3D desktops these days. -- Regards, Hannes Dorbath
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. Now, I find the Debian approach complicated and fiddly, but I suspect that's because what it's doing is complicated and fiddly. -- Richard Huxton Archonet Ltd
On Wednesday 06 June 2007 11:05:00 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: > > - The port is defined in postgresql.conf > - pg_ctl -D defines what cluster to work on > - The switch for the port in psql is -p You also could need to run the proper client application. > 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. The actual fault was mine plus a lack into the manpages. The mechanism could be complicated, but if the needed documentation is up to date and complete, I suspect that a number of people can live with it. -- Vincenzo Romano -- Maybe Computer will never become as intelligent as Humans. For sure they won't ever become so stupid. [VR-1988]
On Wed, Jun 06, 2007 at 11:05:00AM +0200, Hannes Dorbath wrote: > Isn't it funny that stupid wrapper scripts create confusion instead of > making things easier for users. > > Running 2 PG instances is a trivial thing to do. It requires a quick > look at the PostgreSQL documentation to find out that: > > - The port is defined in postgresql.conf > - pg_ctl -D defines what cluster to work on > - The switch for the port in psql is -p That doesn't work if you want to have multiple versions of psql, initdb, pg_dump, or pg_restore. PostgreSQL doesn't support multiple parallel installations of different versions in a transparent way. > 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. Wrappers aren't great, but they're a necessity if you want to be able to run multiple versions of postgres simultaneously in a reasonably transparent way. At least now the package management system can let you install a new version, upgrade an old cluster to a new version and when the upgrade is complete, uninstall the old one. > Anyway, I guess wrappers are a must have like 3D desktops these days. You have an better alternative for handling multiple versions? Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to litigate.
Attachment
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@lfix.co.uk 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
On Wednesday 06 June 2007 13:41:12 Oliver Elphick wrote: > Any suggestions for improvement? As far as "running two or more versions of the PGSQL server in the same machine", I don't see solutions really different from the current one. So I would not waste time and resources in designing a (not really) different solution. But better documentation both as contents and as visibility would close this issue., in my opinion. The solution was in /usr/share/doc/postgresql-<VER>/README.Debian.gz. Some more hints could be extracted from the friendly "man -k clusters". (I personally missed this last point!) But I would have preferred to see an additional paragraph in the standard tools man pages (psql/pg_dump/pg_restore) talking about clusters, pointing to that file and possibly cross referencing to pg_lsclusters. -- Vincenzo Romano -- Maybe Computer will never become as intelligent as Humans. For sure they won't ever become so stupid. [VR-1988]
On Wed, 2007-06-06 at 14:11 +0200, Vincenzo Romano wrote: > On Wednesday 06 June 2007 13:41:12 Oliver Elphick wrote: > > Any suggestions for improvement? > > As far as "running two or more versions of the PGSQL server in the same > machine", I don't see solutions really different from the current one. > So I would not waste time and resources in designing a (not really) different > solution. > > But better documentation both as contents and as visibility would close this > issue., in my opinion. > > The solution was in /usr/share/doc/postgresql-<VER>/README.Debian.gz. > Some more hints could be extracted from the friendly "man -k clusters". > (I personally missed this last point!) > But I would have preferred to see an additional paragraph in the > standard tools man pages (psql/pg_dump/pg_restore) talking about clusters, > pointing to that file and possibly cross referencing to pg_lsclusters. I'll take a look at editing the standard manual pages to mention the Debian add-ons. -- Oliver Elphick olly@lfix.co.uk 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