On Wed, 2002-07-03 at 17:28, Bruce Momjian wrote: > Hannu Krosing wrote: > > > Our very extensibility is our weakness for upgrades. Can it be worked around? > > > Anyone have any ideas? > > > > Perhaps we can keep an old postgres binary + old backend around and then > > use it in single-user mode to do a pg_dump into our running backend. > > That brings up an interesting idea. Right now we dump the entire > database out to a file, delete the old database, and load in the file. > > What if we could move over one table at a time? Copy out the table, > load it into the new database, then delete the old table and move on to > the next. That would allow use to upgrade having free space for just > the largest table. Another idea would be to record and remove all > indexes in the old database. That certainly would save disk space > during the upgrade. > > However, the limiting factor is that we don't have a mechanism to have > both databases running at the same time currently.
How so ? AFAIK I can run as many backends as I like (up to some practical limit) on the same comuter at the same time, as long as they use different ports and different data directories. > Seems this may be > the direction to head in. > > > BTW, how hard would it be to move pg_dump inside the backend (perhaps > > using a dynamically loaded function to save space when not used) so that > > it could be used like COPY ? > > > > pg> DUMP table [ WITH 'other cmdline options' ] TO stdout ; > > > > pg> DUMP * [ WITH 'other cmdline options' ] TO stdout ; > > Intersting idea, but I am not sure what that buys us. Having pg_dump > separate makes maintenance easier. can pg_dump connect to single-user-mode backend ? -------------------- Hannu ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
