Re: About pg_upgrade - Mailing list pgsql-hackers

These are all excellent points.  Peter, I will be out for a few hours so
I can't get to this right away.  If you want to get started, the current
version is in CVS;  feel free to wack it around.  I have been committing
to CVS so people would view/modify it.  I will send you email before I
get started with any changes.

Moving to /contrib I think makes sense, particularly because you need
7.2 pg_upgrade while 7.1 is still installed.   I believe this will
remain true for future releases as well.  I was going to add a mention
of that to pg_upgrade.sgml.

One more change I need which I haven't yet is to force sequence
regeneration even for 7.2 because the XID sequence status changed from
7.2beta4 to 7.2beta5.  I will fix that today.

I had no great plans for pg_upgrade;  I just knew it had to be done some
day and I figured now was a good time.  The group can decide when and
how to use it.

---------------------------------------------------------------------------

Peter Eisentraut wrote:
> I was just looking at the latest pg_upgrade revision.  Maybe it works for
> particular installations, but before we can think about releasing this, at
> least the issues below need to be addressed.
> 
> It seems to require that the data directory is under a directory named
> "data" and that your current directory is above that.  This is not
> appropriate for real software.  I suggest using standard -D options and/or
> the PGDATA environment variable.
> 
> The locations of directories like the INFODIR and the OLDDIR should be
> configurable.  Don't just put them where they happen to fall.  (Remember
> that possibly a lot of data will end up there.)
> 
> The way temp files are allocated looks very insecure.  And does this thing
> even check under what user it's running?
> 
> 'test -e' is not portable.
> 
> 'grep -q' is not portable.  (At least it doesn't portably behave as you
> might think it does.)
> 
> Although 'head' is probably portable, it has never been explored, because
> 'sed 1q' is better.
> 
> If you set an exit trap, then 'exit 1' is not portable.  (I'm not kidding,
> see pg_regress.)
> 
> You can't nest " inside ` inside ".
> 
> Pattern matching with 'expr' should be invoked like this:  expr x"$OBJ" :
> x'pg_', or it might blow up when $OBJ has funny values.
> 
> Moving directories with 'mv' is not necessarily a good idea.
> 
> Should do a lot more error checking.
> 
> psql, pg_ctl, etc. should not just be called from the path.  You know the
> install directory, so use that.
> 
> awk should be called as determined by configure.
> 
> Poor quality (spelling, wording) of messages.
> 
> The man page is very confusing.
> 
> -- 
> Peter Eisentraut   peter_e@gmx.net
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
> 

--  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