Thread: PostGreSQL upgrade failed (Debian Packages), need advice...
This message is in MIME format. ---MOQ1101310591fcc296d4089adf10616d140df3d0355f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit 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. 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? ---MOQ1101310591fcc296d4089adf10616d140df3d0355f--
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
Attachment
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
Attachment
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