Re: Fixing the loss of 'template1'

On Wednesday, March 07, 2012 7:19:51 am Martin Gregorie wrote:
> 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?

The privilege code can be found below, look towards bottom of page:

http://www.postgresql.org/docs/9.1/interactive/sql-grant.html

The privileges look alright, same as mine.

So what user are you trying to restore the pg_dumpall data as?
What is the exact error message you get?

>
> 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

--
Adrian Klaver
adrian(dot)klaver(at)gmail(dot)com