Обсуждение: 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