Thread: 8.1 beta1 -> beta2 upgrade question
Hello, I am a systems admin for OmniTI Inc. I'm posting this question at the request of my boss, Theo Schlossnagle. I am new to Postgres, but Theo has asked me to engage some developers for help, so please bear with me and forgive my ignorance. We are testing a 1TB database on 8.1 beta 1. The upgrade path to beta 2 (and presumably from beta 2 to the next release, all the way through production) requires a full export and import. Even on our beefy hardware (quad-Opteron, 16GB RAM) we are looking at a 26-hour complete outage for every upgrade (and back-out if something doesn't work properly). We are interested in finding a way to directly translate the data files from one version to the next. We can devote resources to work on this if the development team can give us guidance. Thanks in advance, Eric Sproul
On Wed, 2005-10-12 at 11:20 -0600, Aly S.P Dharshi wrote: > Would it be possible to replicate your database to a Slony based beta 2 > and then promote this to a master whilst upgrading the old master ? I > presume that Slony will do the trick with the 8.1 betas Aly, We don't have the online storage to be able to run two instances concurrently. This is the root cause of our desire to upgrade in place. We might not even have enough space for a full logical export-- it would be pretty tight. Eric
Eric Sproul wrote: Hi, > We are testing a 1TB database on 8.1 beta 1. The upgrade path to beta 2 > (and presumably from beta 2 to the next release, all the way through > production) requires a full export and import. Even on our beefy > hardware (quad-Opteron, 16GB RAM) we are looking at a 26-hour complete > outage for every upgrade (and back-out if something doesn't work > properly). We are interested in finding a way to directly translate the > data files from one version to the next. We can devote resources to > work on this if the development team can give us guidance. There has been talk in the past about creating a tool for in-place upgrades. The most complete description of the needed work I've seen posted to date is here: http://archives.postgresql.org/pgsql-hackers/2003-12/msg00379.php There was another proposal after that, http://archives.postgresql.org/pgsql-hackers/2004-09/msg00916.php Neither of them yielded any useful software, that I know of. -- Alvaro Herrera http://www.PlanetPostgreSQL.org "If you have nothing to say, maybe you need just the right tool to help you not say it." (New York Times, about Microsoft PowerPoint)
On Wed, 2005-10-12 at 13:00 -0400, Eric Sproul wrote: > We are interested in finding a way to directly translate the > data files from one version to the next. We can devote resources to > work on this if the development team can give us guidance. Please excuse the followup to myself... We will, of course, be happy to share with the community any improvements that we make as a result of said guidance. Is there someone on the list that I could put in touch with our people to get started? Thanks, Eric
Alvaro Herrera <alvherre@alvh.no-ip.org> writes: > There has been talk in the past about creating a tool for in-place > upgrades. The most complete description of the needed work I've seen > posted to date is here: > http://archives.postgresql.org/pgsql-hackers/2003-12/msg00379.php > There was another proposal after that, > http://archives.postgresql.org/pgsql-hackers/2004-09/msg00916.php > Neither of them yielded any useful software, that I know of. Yeah, I'm afraid I got distracted and never got very far on the first scheme. It still seems perfectly workable, within the limited goals it has --- in particular, it doesn't support changes in the on-disk format of user tables; hence no tuple-header-layout changes or datatype redesigns. But it would work for 99% of the changes we make, and certainly for all cases that seem plausible to happen during beta cycles. I think the second one isn't worth the electrons it's written on, because the smgr API is at far too low a level of abstraction to be able to solve the problem :-( regards, tom lane