Quoting Peter Eisentraut <[EMAIL PROTECTED]>:
> Eric D Nielsen wrote:
> > I recently tried to upgrade from the 7.2.1 PostGreSQL package on
> > Debian Stable to the 7.4.6 PostGreSQL package on Debian Testing. The
> > automatic update failed, message included below. The documentation
> > for manual upgrades references a script which does not appear to
> > exist (postgresql-dump) in the postgres/dumpall/7.2/ directoty.
>
> If the upgrade of the Debian package failed, please submit a bug report
> for the Debian package (after scanning previous bug reports for
> duplicates). That might not help fixing your installation, but at
> least the problem might be corrected in the future.
I've submitted the bug to Debian. Their initial triage appears to suggest
user-error, on my part; I'm not quite accepting that yet. In any case I'm
trying to figure out how to recover my install.
It looks like my attempt to include the script output in my email to the list
got truncated. Here is a brief discussion of what the problems were and what
I've figured out so far.
There were two sets of errors. One set dealing with "FATAL 1: unsupported
frontend protocol" during the data dumping stage of the automatic update
script. It appears that the data was successfully dumped, however. Should I
be worried? Is this FATAL warning actually routine? Why would it pop up but
still appear to finish the dump successfully?
SCRIPT OUTPUT
Stopping and restarting the postmaster
/var/lib/postgres/dumpall/7.2/postmaster -D /var/lib/postgres/data -p 5431 -o
-d0
DEBUG: database system was shut down at 2004-11-24 07:17:34 EST
DEBUG: checkpoint record is at 1/A1C26620
DEBUG: redo record is at 1/A1C26620; undo record is at 0/0; shutdown TRUE
DEBUG: next transaction id: 73576388; next oid: 446733
DEBUG: database system is ready
Dumping the database to /var/lib/postgres//db.out
pg_dumpall -N
Dumping with new pg_dumpall
FATAL 1: unsupported frontend protocol
... ~30 lines of the same FATAL error repeat
END SCRIPT OUTPUT
The second set of errors were caused by disappearance of the "debug-level"
configuration parameter and by the upgrade script not over-writing the
configuration file with a new one. (This is where the user-error claim is
arising. I don't recall denying permission to overwrite, but the script is
acting as if I did.)
Relevant output:
creating directory /var/lib/postgres/data/base... ok
creating directory /var/lib/postgres/data/global... ok
creating directory /var/lib/postgres/data/pg_xlog... ok
creating directory /var/lib/postgres/data/pg_clog... ok
selecting default max_connections... 100
selecting default shared_buffers... 1000
ok
creating template1 database in /var/lib/postgres/data/base/1... FATAL:
unrecognized configuration parameter "debug_level"
initdb: failed
initdb failed
END OUTPUT
In this case the initdb didn't clean up the partially populated PGDATA
directory, should it have?
I've gone in and manually removed the offending line in the configuration file.
Now I try to initdb manually and I receive
[EMAIL PROTECTED]:~$ initdb --debian-conffile
use debian conffile location
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.
The database cluster will be initialized with locale C.
creating directory /var/lib/postgres/data... ok
creating directory /var/lib/postgres/data/base... ok
creating directory /var/lib/postgres/data/global... ok
creating directory /var/lib/postgres/data/pg_xlog... ok
creating directory /var/lib/postgres/data/pg_clog... ok
selecting default max_connections... 100
selecting default shared_buffers... 1000
/usr/lib/postgresql/bin/initdb: line 648: /etc/postgresql/4122: Permission
denied
initdb: failed
initdb: removing data directory "/var/lib/postgres/data"
END OUTPUT
How do I proceed here? It looks like a permission issue, but there is no file
by that name in that directory.
Assuming that this issue is resolved and I can initdb and restart postmaster
what is the series of actions to finish recovery?
1. psql template1 < db.out
db.out is the all database dump, so it will create and connect to the
individual databases. Or is there a dedicated restore tool I should be using?
2. adddepend? I'm coming from 7.2 to 7.4 so I beleive I'm supposed to run this,
but I haven't found documentation on it yet... Do I run it before restore on
the sql dump or against the live DB, etc? I assume this answer is in the
mailing list archive, but searching hasn't been working for me all day.
3. Anything else?
Thank you.
Eric
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
