Skip site navigation (1) Skip section navigation (2)

Re: pg_dumpall (7.1beta1, current CVS)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Larry Rosenman <ler(at)lerctr(dot)org>
Cc: PostgreSQL Hackers List <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_dumpall (7.1beta1, current CVS)
Date: 2001-01-01 19:16:05
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Larry Rosenman <ler(at)lerctr(dot)org> writes:
> I noticed today that pg_dumpall from current CVS does *NOT*
> dump a password assiged to the postgres user.  

> I consider this BAD, since if one has to restore from
> a pg_dumpall, one may forget to reset the password. 

I'm unconvinced.  The pg_dumpall script is clearly intended to allow
restoration into a new database installation with a different superuser;
you will note that the script is careful not to assume that the old and
new superuser names are the same (an assumption your proposed patch
does make).

In any case the new installation certainly already *has* a superuser.
I'm not sure it's the job of the restore script to change his password
for him.

This does point up that there is some state that is not saved/restored
by pg_dumpall --- the pg_hba.conf file and other config files that
live in $PGDATA come to mind.  Perhaps there should be a separate
utility that saves/restores these.  (pg_dump can't do it because there's
no way to retrieve these files through a database connection.)

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2001-01-01 19:19:00
Subject: Re: Current Sources/UW7.1.1
Previous:From: Chih-Chang HsiehDate: 2001-01-01 12:32:48
Subject: Re: [HACKERS] About PQsetClientEncoding(),"SET NAMES",and "SET CLIENT_ENCODING"

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group