Bug 16416

WRT 2) - the only codepath leading there is "destroy", isn't it?

WRT 2)The startup script checks for both data directory possibilities, allowing the DBA to move the datadir at a convenient time.
/etc/rc.d/init.d/postgresql will start postmaster onto either directory, the last I checked.  So, postgresql-dump doesn't handle this 
currently -- the initscript deals with either case.

The reason I wrote it that way is to prevent data lossage if at all possible.  Making a mistake with user's data under an RDBMS is not a fun thing.

The long term solution is to judiciously use mv to relocate the individual dirs under the old PGDATA to the new PGDATA -- can't copy and remove,
as disk space can become an issue.

As to the README.rpm typo, that will need to be changed to reflect the actual backup directory name.

I didn't check what the init script will do or won't do, I tried to start postgres, it complained that I had
to run that script to upgrade, I did it and it failed to produce a new database. All I have is the old db and
the old binaries. In my case, having a complete dump, it is easier to do a manual reload, but what if
I hadn't taked this precaution?
People trust the installer to take care of this. A friend of mine stopped using RH when an upgrade (to 6.2, I believe) completely clobbered his postgres
installation, so I suppose this is a MUST-FIX-OR-ELSE thing because many people are going to be
savagely bitten by this one.

OK. Then the first claim, than an reordering is necesarry, is also possibly
wrong?

The code above the assignments is only defining functions.

The upgrade isn't done automatically to ensure the safety of the data. Did you
follow the instructions given on startup?

/usr/doc vs. /usr/share/doc has been fixed.

Just to be sure, repeated everything again. Setup 6.2, loaded postgresql with a database from another
machine (via dump and reload), upgraded to RC1 and here we are:

- first claim is valid: between the function definitions and the definition of PGDATA, there's some code
that depends on PGDATA being set, otherwise bash complains about expecting a unary operator.
(see postgresql-dump.patch, sorry I wasn't accurate in my first report).

- db upgrade: /etc/init.d/postgresql start: "need to upgrade, see ... README.rpm". Ok.
README.rpm: use postgresql-dump with this cmdline, then start, then reload. Ok.
Become user postgres.
Got "unary operator expected", applied my fix (as root), solved.
Retry script.
"The PostgresQL data... and the dump file are missing".
Read manpage. Try "-u". Same result. Give up.
(see runscript.out and pgsql.dirlist for the output from bash with -x and my pgsql directory contents).

Created attachment 2739 [details]
Fix for "unary operator expected"

Created attachment 2740 [details]
Output from postgresql-dump script (set -x in bash)

Created attachment 2741 [details]
Directory listing of postgresql installation

Lamar, any ideas?

I've moved the variable definitons to the top, BTW.

OK... - Lamar, your script is very broken. Working on it. 

For reproducing: remove postgresql RPMs, install readline and postgresql RPMS
from 6.2, create a database and try upgrading.

Created my own script for handling this.... thanks a lot for this report.

Would you mind sharing it with me? I'd like to give it some hard time and really be paranoically sure that it works fine.

Created attachment 2918 [details]
new dump script.

Ok, it creates a valid dump, but it should also must also move old db out of the way so that psql
initscript does not complain again about the need for an upgrade.
Have you updated the README, btw?
Good job for the script, anyway.

This is updated in the updated README.rpm, which points at this script.

Is it possible to download the updated rpms? Where do I find them?