Thread: Downlevel database
We have a problem with a PosgreSQL database where the user cannot get to their tables any more. I am not the primary administrator of this host (who is on vacation), nor am I the user of this database. The /var/log/posgresql file has entries like the following, at the end: FATAL 1: Database "trees_rock" does not exist in the system catalog. The current running version of the database is 7.2.2, and I suspect the database was created and maintained with 7.3.4 (after examining the bash history file for user postgres). Would running downlevel software cause this problem? Does this seem likely or possible? Now that the old database software is running on the new data, what do I do to recover? -- Gary Jackson bargle@umiacs.umd.edu
Gary Jackson <bargle@umiacs.umd.edu> writes: > We have a problem with a PosgreSQL database where the user cannot get > to their tables any more. I am not the primary administrator of this > host (who is on vacation), nor am I the user of this database. The > /var/log/posgresql file has entries like the following, at the end: > FATAL 1: Database "trees_rock" does not exist in the system catalog. > The current running version of the database is 7.2.2, and I suspect the > database was created and maintained with 7.3.4 (after examining the > bash history file for user postgres). > Would running downlevel software cause this problem? Does this seem > likely or possible? No, no, and no. A 7.2.anything server would flat out refuse to start in a 7.3.* database (because it checks PG_VERSION). You might have been using 7.3 client-side code to talk to the 7.2 server, but that wouldn't cause this sort of failure. A possible quick-and-dirty solution is "VACUUM pg_database" (issued from any of the databases that you can get into). If that doesn't work then you've got serious problems :-( regards, tom lane
On Feb 4, 2005, at 12:08 PM, Tom Lane wrote: > > No, no, and no. A 7.2.anything server would flat out refuse to start > in > a 7.3.* database (because it checks PG_VERSION). You might have been > using 7.3 client-side code to talk to the 7.2 server, but that wouldn't > cause this sort of failure. > > A possible quick-and-dirty solution is "VACUUM pg_database" (issued > from > any of the databases that you can get into). If that doesn't work then > you've got serious problems :-( > > regards, tom lane > The 7.3 data directory was actually elsewhere -- duh on me. Thanks for the help! -- Gary Jackson bargle@umiacs.umd.edu