Re: Re: [GENERAL] 7.0 vs. 7.1 (was: latest version?)
От | Lamar Owen |
---|---|
Тема | Re: Re: [GENERAL] 7.0 vs. 7.1 (was: latest version?) |
Дата | |
Msg-id | 39FA00E5.BDD698AA@wgcr.org обсуждение исходный текст |
Ответ на | Re: Re: [GENERAL] 7.0 vs. 7.1 (was: latest version?) (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: Re: [GENERAL] 7.0 vs. 7.1 (was: latest version?)
(Peter Eisentraut <peter_e@gmx.net>)
|
Список | pgsql-hackers |
Bruce Momjian wrote: > > > However, the upgrade gotcha has left a very bitter taste in more than > > one user's mouth. I'll not say more about that now, as I've said quite > > enough in the past. And I'm still trying to figure out enough of the > > internals of the storage manager to try to write the migration tools > > myself. But, I have other fish to fry right now, the biggest being > > cross-distribution RPM's. > > Actually, I would prefer to see how we can improve what we have before > making a binary conversion utility that will have to be updated for > every release. > > > Meet Mr. Middle Layer. :-) The PostgreSQL spec file that controls the > > RPM build is one of the most complex ones in the RedHat distribution, > > AFAIK. There's the middle layer. It does quite a bit of finagling > > already. > > Yes, I suspected the RPM was the middle layer. To the extent we can > make that easier, let's hear it. Tell us what you need to do, and what > you can't do, and see if any of us can figure out how to make things > easier. Ok, here goes: * Location-agnostic installation. Documentation (which I'll be happy to contribute) on that. Peter E is already working in this area. Getting the installation that 'make install' spits out massaged into an FHS compliant setup is the majority of the RPM's spec file. * Upgrades that don't require an ASCII database dump for migration. This can either be implemented as a program to do a pg_dump of an arbitrary version of data, or as a binary migration utility. Currently, I'm saving old executables to run under a special environment to pull a dump -- but it is far from optimal. What if the OS upgrade behind 99% of the upgrades makes it where those old executables can't run due to binary incompatibility (say I'm going from RedHat 3.0.3 to RedHat 7 -- 3.0.3, IIRC, as a.out...( and I know 3.0.3 didn't have PostgreSQL RPMs).)? What I could actually do to prevent that problem is build all of PostgreSQL's 6.1.x, 6.2.x, 6.3.x, 6.4.x, and 6.5.x and include the necessary backend executables as part of the RPM.... But I think you see the problem there. However, that would in my mind be better than the current situation, albeit taking up a lot of space. * A less source-centric mindset. Let's see, how to explain? The regression tests are a good example. You need make. You need the source installed, configured, and built in the usual location. You need portions of contrib. RPM's need to be installable on compiler-crippled servers for security. While the demand for regression testing on such a box may not be there, it certainly does give the user something to use to get standard output for bug reports. As a point, I run PostgreSQL in production on a compilerless machine. No compiler == more security. And Linux has enough security problems without a compiler being available :-(. Oh, and I have no make on that machine either. The documentation as well as many of the examples assume too much, IMHO, about the install location and the install methodology. I think I may have a solution for the library versioning problem. Rather than symlink libpq.so->libpq.so.2->libpq.so.2.x, I'll copy libpq.so.2.1 to libpq.so.2 and symlink libpq.so to that. A little more code for me. There is no real danger in version confusion with RPM's versioning and upgrade methodology, as long as you consistently use the RPMset. The PostgreSQL version number is readily found from an RPM database query, making the so version immaterial. The upgrade issue is the hot trigger for me at this time. It is and has been a major drain on my time and effort, as well as Trond's and others, to get the RPM upgrade working even remotely smoothly. And I am willing to code -- once I know how to go about doing it in the backend. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
В списке pgsql-hackers по дате отправления: