Re: pg_dump/pg_dumpall

"Andrew C. Uselton" <acuselton(at)lbl(dot)gov> writes:
> I am beginning to understand a little better. Our database is
> configured with the pg_hba.conf entry (the only entry):

> local all all md5 sameuser

It's a bit late at night, but I'm fairly sure that the "sameuser" option
is ignored here. If md5 is the only auth method allowed then you should
have to give a password to get in.

> The database cluster was created (initdb) in the default way, with no
> -pwpromt. Either a superuser password was never created or (less
> likely) we just don't know what it is. According to the administrative
> reference if there is no superuser password you can't authenticate
> against the "postgres" superuser at all. This appears to be harmless
> (i.e. not having a superuser password) for things like (as root):

> su -l postgres -c "/usr/bin/createuser ..."

Well, if that works then there's something going on here that you didn't
tell us. Perhaps postgres has a ~/.pgpass file to provide its password?
If not, I have to guess that you're looking at the wrong pg_hba.conf,
or that it doesn't describe what the server's really doing (ie it was
changed but the server was never restarted or SIGHUP'd since then).

The usual way of forcing things into a sane state if you're presented
with a database you can't get into is to change pg_hba.conf to allow
trust or ident auth (don't use trust if there are people you don't trust
allowed to log into the machine), and restart the server. Then you can
log in as the postgres user and set its password; then change
pg_hba.conf to the configuration you want and SIGHUP again.

regards, tom lane