People,
On 2011-11-26 09:46, Chris Travers wrote: > On Fri, Nov 25, 2011 at 6:08 AM, David A. Bandel > <[email protected]> wrote: >> On Thu, Nov 24, 2011 at 18:11, Chris Travers >> <[email protected]> wrote: >> >> [snip] >> >>> >>> Ok. So with a server, my primary concern is that upgrading things >>> is >>> always a somewhat risky process. Basically, when you upgrade, you >>> risk breaking things, so generally speaking you want to have longer >>> terms of support and a more lazy upgrade cycle. And there are a >>> couple things about the Fedora upgrade process that are >>> particularly >>> risky. For example yum distrosync will upgrade major versions of >>> PostgreSQL for you, meaning if you didn't dump your data first, >>> your >>> PostgreSQL db is now unusable. >> >> I hope you're joking. While a Debian upgrade is not the easiest >> thing >> in the world (they do their best to make it so, though), at least >> this >> is not an issue. You run postgresql versions in parallel until you >> finally get rid of the old one because the new one works properly >> for >> you. > > I am not joking. I always back up before an upgrade.... > fortunately.... but I have noticed this happen. I do a nightly pg_dump (in text mode these days ie not natively compressed) and again just before the upgrade if necessary. So I can just import back into the new DB. I keep as many daily backups as my backup drive allows and only delete old days when space starts running short (but I still keep EOM backups). It hasn't failed me so far but in this case I do not have to worry about having to upgrade from LSMB 1.2 to 1.3 - my other PG stuff doesn't have the same issues I guess . . >> I've gone through 8.4->9.0->9.1 (and many before I can't remember) >> upgrades w/ no problem (personally I use testing, even for my own >> servers). With Debian, they leave both database versions running >> until you've dealt with any upgrade issues. So far, I've only had >> one, that was when a contrib stored procedure I was using didn't >> make >> it from 8.4->9.0 (but it appeared again in 9.1). > > That's the right way to do things. Agreed. Regards, Phil. -- Philip Rhoades GPO Box 3411 Sydney NSW 2001 Australia E-mail: [email protected] ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d _______________________________________________ Ledger-smb-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
