On Tue, 3 Aug 1999, Dmitry Morozovsky wrote:
> On Mon, 2 Aug 1999, Peter Eisentraut wrote:
>
> PE> > How can I organize automated database dumping for passord protected
> PE> > database?
> PE> If you're implying something like "How do I get around entering a
> PE> password?", that won't be solvable so easily. Possibly you want to use
> PE> ident authentication for that particular user and host or hardcode the
> PE> password in your (preferably read-protected) script. (If anyone has better
> PE> ideas here, let us know.)
>
> Yes, surely, I meant precisely this situation. I have looked through sources of
> pg_dump, but have no time to patch it to achieve desired effect :)
Patching pg_dump to circumvent password protection would create a serious
security hole! In that case everyone could easily get to the data anyway.
The security system in PostgreSQL has come under some criticism recently,
so for now I think you're stuck with the options above.
>
>
> PE> A different solution would be to backup the $PGDATA/base directory using
> PE> regular file backup methods. That wouldn't be a dump, so it depends on
> PE> your particular needs.
>
> This may not have the desired effect, as the database may be not in
> consistent state.
>
> Or am I wrong presuming that pg_dump locks entire database for update?
pg_dump does not lock the database. That is at least what I gather from
the following advice in the installation procedure, step 6:
Caution: You must make sure that your database is not updated in the
middle of your backup. If necessary, bring down postmaster, edit the
permissions in file /usr/local/pgsql/data/pg_hba.conf to allow only you
on, then bring postmaster back up. [before running pg_dumpall]
On the other hand, pg_dump guarantees you that you have *some* consistent
state of the database (not necessarily the latest, see MVCC). If you
backup the data directory during a write, who knows what you'll get. (Can
anyone tell me?)
--
Peter Eisentraut
PathWay Computing, Inc.
