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