Re: (A) native Windows port

Lamar Owen wrote:
> On Wednesday 03 July 2002 12:09 pm, Bruce Momjian wrote:
> > Hannu Krosing wrote:
> > > 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.
> 
> > We don't have an automated system for doing this.  Certainly it is done
> > all the time.
> 
> Good.  Dialog.  This is better than what I am used to when I bring up 
> upgrading. :-)
> 
> Bruce, pg_upgrade isn't as kludgey as what I have been doing with the RPMset 
> for these nearly three years.
> 
> No, what I envisioned was a standalone dumper that can produce dump output 
> without having a backend at all.  If this dumper knows about the various 
> binary formats, and knows how to get my data into a form I can then restore 
> reliably, I will be satisfied.  If it can be easily automated so much the 
> better.  Doing it table by table would be ok as well.

The problem with a standalone dumper is that you would have to recode
this for every release, with little testing possible.  Having the old
backend active saves us that step.  If we get it working, we can use it
over and over again for each release with little work on our part.

> Keys to this working:
> 1.)    Must not require the old version executable backend.  There are a number 
> of reasons why this might be, but the biggest is due to the way much 
> upgrading works in practice -- the old executables are typically gone by the 
> time the new package is installed.

Oh, that is a problem.  We would have to require the old executables.

> 2.)    Uses pg_dbdump of the new version.  This dumper can be tailored to provide 
> the input pg_restore wants to see.  The dump-restore sequence has always had 
> dumped-data version mismatch as its biggest problem -- there have been issues 
> before where you would have to install the new version of pg_dump to run 
> against the old backend.  This is unacceptable in the real world of binary 
> packages.
> 
> One other usability note: why can't postmaster perform the steps of an initdb 
> if -D points to an empty directory?  It's not that much code, is it?  (I know 
> that one extra step isn't backbreaking, but I'm looking at this from a rank 
> newbie's point of view -- or at least I'm trying to look at it in that way, 
> as it's been a while since I was a rank newbie at PostgreSQL)  Oh well, just 
> a random thought.

The issue is that if you have PGDATA pointed to the wrong place, it
creates a new instance automatically.  Could be strange for people, but
we could prompt them to run initdb I guess.

> But I believe a backend-independent data dumper would be very useful in many 
> contexts, particularly those where a backend cannot be run for whatever 
> reason, but you need your data (corrupted system catalogs, high system load, 
> whatever).  Upgrading is just one of those contexts.

Yes, but who wants to write one of those for every release?  That is
where we get stuck, and with our limited resources, it is desirable to
encourage people to work on it?

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026