Re: 7.1 Release Date
От | Lamar Owen |
---|---|
Тема | Re: 7.1 Release Date |
Дата | |
Msg-id | 39AC14AF.71DFDF9C@wgcr.org обсуждение исходный текст |
Ответ на | Re: 7.1 Release Date (The Hermit Hacker <scrappy@hub.org>) |
Список | pgsql-general |
Trond Eivind Glomsrød wrote: > For Red Hat 4.x, that would be true - we don't support the ancient > libc5 anymore (OTOH, we didn't include Postgres95 at the time either). There were RPM's at the time, though -- I ran 6.1.1 for nearly a year on RedHat 4.1 until I upgraded to RH 5 (which shipped 6.2.1) after being cracked. Good thing it was a reinstall from scratch -- those 6.1.1 RPMs were _very_ different from what RedHat shipped in 5.0. > > Note that ANY RPM-based distribution is going to have this same > > problem. > Not just RPM-based - any distribution who upgrades when the system is > offline. Like Debian. Of course, the RPM postgresql-dump script came from the Debian packages -- so Oliver knows where I'm coming from. However, Debian upgrading is more intelligent in many areas than RPM upgrading is. > > Yes, Tom, the RPM-based OS's upgrade procedures are brain-dead. > No, it's not - it's just not making assumptions like "enough space is > present to dump everything somewhere" (if you have a multiGB database, > dumping it to upgrade sounds like a bad idea), "the database server is > running, so I can just dump the data" etc. 'Brain-dead' meaning WRT upgrading RPMs...: 1.) I can't start a backend to dump data if the RPM is installing under anaconda; 2.) I can't check to see if a backend is running (as an RPM pre or post script can't use ps or cat /proc reliably (according to Jeff Johnson) if that pre or post script is running under anaconda); 3.) I can't even check to see if the RPM is installing under anaconda! (ie, to have a more interactive upgrade if the RPM -U is from the command line, a check for the dump, or a confirmation from the user that he/she knows what they're getting ready to do) -- in fact, I would prefer to abort the upgrade of postgresql RPM's in anaconda as it currently stands -- but that might easily abort the whole install! 4.) I'm not guaranteed of package upgrade order with split packages; 5.) I'm not even guaranteed to have basic system commands available, unless I Prereq: them in the RPM (which is the fix for that); 6.) The installation chroot system is flakey (again, according to Jeff Johnson) -- the least things you do, the better. My current backing up of the old executables was really more than Jeff wanted to see. Maybe this is fixed in Pinstripe. 7.) The requirements and script orders are not as well documented as one might want. 8.) If I need to do complex operations to upgrade a package, it shouldn't be a problem to do so in a pre install script -- but it is a big problem. There _are_ other packages that require some _interesting_ steps to upgrade.... > > But, it can also be argued that our dump/restore upgrade procedure > > is also brain-dead. > This is basically "no upgrade path. But you can dump your old data > before upgrading. And you can insert data in the new database". Vegetable upgrades. You have really trimmed it to essentials -- PostgreSQL has no upgrade path in actuality. I seem to remember several messages to this list in the past about problems with restoring data dumped under older versions.... Upgrades should just be this simple: Install new version. Start new version's postmaster, which issues a 'pg_upgrade' in safest mode. If pg_upgrade fails for any reason, get DBA intervention, otherwise, just start the postmaster already! This could just as easily be: Install new version. Run pg_upgrade if required. Start postmaster, and it just runs. It SHOULD be that simple. It CAN be that simple. Effort HAS been expended already on this issue -- there is a pg_upgrade script already written that tries to do some of this, but without actually translating the contents of the relation files. Maybe we should file this as a bug against pg_upgrade :-). -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
В списке pgsql-general по дате отправления: