Re: (A) native Windows port

From: Hannu Krosing <hannu(at)tm(dot)ee>
To: Oliver Elphick <olly(at)lfix(dot)co(dot)uk>
Cc: "Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Lamar Owen <lamar(dot)owen(at)wgcr(dot)org>, Jan Wieck <JanWieck(at)Yahoo(dot)com>, Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, HACKERS <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: (A) native Windows port
Date: 2002-07-09 17:46:10
Message-ID: 1026236770.7042.183.camel@taru.tm.ee
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

On Tue, 2002-07-09 at 18:30, Oliver Elphick wrote:
> On Tue, 2002-07-09 at 18:05, Hannu Krosing wrote:
> > The big change was from 6.x to 7.x where a chunk of data moved from end
> > of page to start of page and tableoid column was added. Otherways the
> > table structure is quite simple. The difficulties with user _data_ can
> > be mainly because of binary format changes for some types and such.
> >
> > But I still can't see how will having a binary dumper that does mostly
> > the work of [ old_backend -c "COPY tablex TO STDOUT" ] help us here.
> >
> > IIRC the main difficulties in upgrading have always been elsewhere, like
> > migrating always changing system table data.
>
> The main problem is getting access to the user data after an upgrade.

Can't it be dumped in pre-upgrade script ?

> There's no particular problem in having to do an initdb, though it is an
> inconvenience; the difficulty is simply that any packaged distribution
> (rpm, deb, xxx) is going to have to replace all the old binaries. So by
> the time the package is ready to do the database upgrade, it has
> destroyed the means of dumping the old data. Lamar and I have to jump
> through hoops to get round this -- small hoops with flaming rags round
> them!

IMHO, if rpm and apt can't run a pre-install script before deleting the
old binaries they are going to replace/upgrade then you should complain
to authors of rpm and apt.

It seems that they are doing things in wrong order.

The right order should of course be

1) run pre-upgrade (pg_dumpall >dumpfile)
2) upgrade
3) run post-upgrade (initdb; psql < dumpfile)

---------------
Hannu

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message pgsql-gen Newsgroup (@Basebeans.com) 2002-07-09 17:55:02 Re: Announce: J2EE MVC training using Struts with Standard Tags (JSTL)
Previous Message Marc G. Fournier 2002-07-09 17:45:57 Re: I am being interviewed by OReilly

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Treat 2002-07-09 18:06:20 Re: I am being interviewed by OReilly
Previous Message Marc G. Fournier 2002-07-09 17:45:57 Re: I am being interviewed by OReilly