BUG #4127: pg_dumpall -c unable to be restored without error

Started by Jacob Champlinalmost 18 years ago3 messagesbugs
Jump to latest
#1Jacob Champlin
jacobc@rentec.com

The following bug has been logged online:

Bug reference: 4127
Logged by: Jacob Champlin
Email address: jacobc@rentec.com
PostgreSQL version: 8.1.11
Operating system: SuSE 10.1
Description: pg_dumpall -c unable to be restored without error
Details:

In 8.0 I would do a pg_dumpall -c to backup my database.

In 8.1 you guys have added functionality to the -c flag to make it now DROP
and Recreate Roles. Nice feature and seems to be the right thing to do.

However, with the DROP Roles in the file this causes the file to not be able
to be restored.

psql -f restore.sql

results in:

psql:/var/lib/pgsql/backups/restore.sql:11: ERROR: current user cannot be
dropped
psql:/var/lib/pgsql/backups/restore.sql:12: ERROR: role "postgres" already
exists
psql:/var/lib/pgsql/backups/restore.sql:17: ERROR: role "webapp" cannot be
dropped because some objects depend on it
DETAIL: access to database rief
113 objects in database rief
psql:/var/lib/pgsql/backups/restore.sql:18: ERROR: role "webapp" already
exists

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Jacob Champlin (#1)
Re: BUG #4127: pg_dumpall -c unable to be restored without error

"Jacob Champlin" <jacobc@rentec.com> writes:

psql -f restore.sql

results in:

psql:/var/lib/pgsql/backups/restore.sql:11: ERROR: current user cannot be
dropped
psql:/var/lib/pgsql/backups/restore.sql:12: ERROR: role "postgres" already
exists
psql:/var/lib/pgsql/backups/restore.sql:17: ERROR: role "webapp" cannot be
dropped because some objects depend on it
DETAIL: access to database rief
113 objects in database rief
psql:/var/lib/pgsql/backups/restore.sql:18: ERROR: role "webapp" already
exists

And? The restore would've proceeded anyway.

regards, tom lane

#3Jacob Champlin
jacobc@rentec.com
In reply to: Tom Lane (#2)
Re: BUG #4127: pg_dumpall -c unable to be restored without error

And if this is expected correct behavior it shouldn't throw an error....

This is especially problematic for automated processes, in which you
only want to know when they fail.

Its possible to ignore error messages, but then when something real does
go wrong you lose those.

Don't get me wrong I know this is not the end of the world, but I also
think its the wrong behavior, one that is problematic for me.

Jacob

Tom Lane wrote:

Show quoted text

"Jacob Champlin" <jacobc@rentec.com> writes:

psql -f restore.sql

results in:

psql:/var/lib/pgsql/backups/restore.sql:11: ERROR: current user cannot be
dropped
psql:/var/lib/pgsql/backups/restore.sql:12: ERROR: role "postgres" already
exists
psql:/var/lib/pgsql/backups/restore.sql:17: ERROR: role "webapp" cannot be
dropped because some objects depend on it
DETAIL: access to database rief
113 objects in database rief
psql:/var/lib/pgsql/backups/restore.sql:18: ERROR: role "webapp" already
exists

And? The restore would've proceeded anyway.

regards, tom lane