Re: Problems when dumping a database

From: Tressens Lionel <tressens(at)etud(dot)insa-tlse(dot)fr>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Problems when dumping a database
Date: 2001-02-22 18:55:16
Message-ID: Pine.LNX.4.10.10102221926270.10722-100000@jaures.etud.insa-tlse.fr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Le 20.02.01 à 13:18, "Tom Lane" écrivait :

)Tressens Lionel <tressens(at)etud(dot)insa-tlse(dot)fr> writes:
)> My pgsql DBMS works great except that when I want to dump a database,
)> pg_dump says that database template1 doesn't exist (actually it does !)
)> and the dump is aborted...
)
)Curious. Can you connect to template1 by hand (eg "psql template1")?

Yes I can. But something strange is that I can use the tables of the
template1 database :

template1=> select * from pg_shadow; (this will work)

But I cannot list them :

template1=> \d
Couldn't find any tables, sequences or indices!

)If not, try issuing "vacuum pg_database" (you can do this from any
)database not only template1) to see if it helps.

Doesn't change nothing in my case...

)If that doesn't fix it, we'll need to see the exact output from pg_dump,
)as well as what shows up in the postmaster log.

Output of pg_dump :
$ pg_dump tressens -u
Username: tressens
Password:

pg_dump: couldn't find the template1 database. You are really hosed.
Giving up.

Nothing strange in the logs but I typed by hand what postmaster does when
he's looking for template1 in pg_database :
SELECT oid FROM pg_database WHERE datname = 'template1'

But this SELECT returns two tuples ! I have two identical tuples in
pg_database for template1.
Perhaps deleting one will help me, but which one (equal ?).

What do you think about it ?

Thanks a lot.

Lionel

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Paulo Parola 2001-02-22 19:07:06 PostgreSQL 7.1 Linux Installation
Previous Message Bruce Momjian 2001-02-22 18:54:16 Re: access to internal rowIds