Re: About pg_upgrade

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: About pg_upgrade
Date: 2002-01-13 15:03:50
Message-ID: 200201131503.g0DF3o206523@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)gmx(dot)net
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
>

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Brent Verner 2002-01-13 15:30:19 Re: Problem reloading regression database
Previous Message mlw 2002-01-13 14:56:23 Re: mysql-pgsql comparison