Re: Fixing the loss of 'template1'

On Wed, 2012-03-07 at 09:38 -0500, Gary Chambers wrote:
> Martin,
>
> > 6) The next scheduled backup using pg_dumpall failed immediately because
> > it couldn't find 'template1'.
>
> The template1 database is the default database to which pg_dumpall attempts
> to connect. If you use the -l or --database option, you can change that and
> pg_dumpall will resume functioning as you expect.
>
I've just logged in under postgres and run '\l' - and the databases
postgres, template0 and template1 are still there:

postgres=# \l
List of databases
Name | Owner | Encoding | Collate | Ctype | Access
privileges
-----------+----------+----------+-------------+-------------+-----------------------
postgres | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 |
template0 | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 |
=c/postgres +
| | | | |
postgres=CTc/postgres
template1 | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 |
postgres=CTc/postgres+
| | | | |
=c/postgres

So, is this a privilege issue? I don't understand the content of that
somewhat cryptic 'privilege' column. Is it set how you'd expect?

Marti:
======
I got this output:

postgres=# SELECT datname FROM pg_database WHERE datistemplate;
datname
-----------
template0
template1
(2 rows)

so it doesn't look like its been renamed.

Martin