PostGreSQL upgrade failed (Debian Packages), need advice...

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.

Can anyone advise me of how to proceed? I would prefer to stick with the
Debian
packages, but if I must can deal with compiling from source for intermediate
versions, etc.

Well you can't just "upgrade" 7.2.1 to 7.4.6. You have to dump and restore.
My suggestion would be to dump your 7.2.1 database and if you can use
the 7.4.6 pg_dump (from source). Then remove 7.2.1 and try and reinstall
7.4.6.
Once 7.4.6 is installed then restore your dump and you should be good to go.

Sincerely,

Joshua D. Drake

Thank you.

Eric Nielsen

----- Begin script output
The postmaster did not start after postgresql was installed:

Stopping PostgreSQL database server: postmasterpg_ctl: could not find
/var/lib/postgres/data/postmaster.pid
Is postmaster running?
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

-- 
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com
PostgreSQL Replicator -- production quality replication for PostgreSQL

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.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Joshua D. Drake wrote:

Well you can't just "upgrade" 7.2.1 to 7.4.6. You have to dump and
restore.

The Debian package does that automatically. On some days...

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Peter Eisentraut wrote:

Joshua D. Drake wrote:

Well you can't just "upgrade" 7.2.1 to 7.4.6. You have to dump and
restore.

The Debian package does that automatically. On some days...

Really? WOW! I wonder if Gentoo does that. That is pretty
remarkable.

Sincerely,

Joshua D. Drake

-- 
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com
PostgreSQL Replicator -- production quality replication for PostgreSQL

On Wed, 2004-11-24 at 08:30 -0800, Joshua D. Drake wrote:

Peter Eisentraut wrote:

Joshua D. Drake wrote:

Well you can't just "upgrade" 7.2.1 to 7.4.6. You have to dump and
restore.

The Debian package does that automatically. On some days...

Really? WOW! I wonder if Gentoo does that. That is pretty
remarkable.

Gentoo tells you that you need to dump and remove the cluster before it
evens tries to upgrade, atleast did for me when going from 7.3 to 7.4

regards,
Robin

Quoting Peter Eisentraut <peter_e@gmx.net>:

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
postgres@ballroom:~$ 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

Eric D Nielsen <nielsene@MIT.EDU> writes:

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?

It is if you are using a 7.4 or later client to talk to a 7.3 or older
server. The client will first attempt to connect with 7.4 protocol, and
only fall back to the older protocol when that fails. This leaves a
harmless gripe behind in the server's log...

Dumping with new pg_dumpall
FATAL 1: unsupported frontend protocol

... and evidently that's exactly what the script is doing. I'm not sure
why it's intermixing the server's log output with its own commentary
though.

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

Can't speak to this one. It could be a file-permissions kind of failure?

In this case the initdb didn't clean up the partially populated PGDATA
directory, should it have?

Depends how the script invoked initdb --- there's a command line option
telling it which to do.

/usr/lib/postgresql/bin/initdb: line 648: /etc/postgresql/4122: Permission
denied

How do I proceed here? It looks like a permission issue, but there is no file
by that name in that directory.

This seems to be related to Debian's local changes to Postgres; you'll
have to read their documentation to figure out what's up. Or at least
look at their version of the initdb script (in the stock 7.4 script,
line 648 is noticeably further down than you evidently got).

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

Check.

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

Look at contrib/addepend/README (not sure where Debian puts this, but
it's there in the source tree).

regards, tom lane