From: | Adrian Klaver <adrian(dot)klaver(at)gmail(dot)com> |
---|---|
To: | Chris Curvey <ccurvey(at)zuckergoldberg(dot)com> |
Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: help getting a backtrace from 9.2 on Ubuntu 13.04? |
Date: | 2013-09-10 22:26:30 |
Message-ID: | 522F9C96.7080307@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 09/10/2013 10:37 AM, Chris Curvey wrote:
>
> Another development (possibly unrelated): I tried **dumping** with
> –no-privileges –no-tablespace –no-owner, and the restore went fine.
>
Probably has to do with whether you are dumping plain text or custom format:
http://www.postgresql.org/docs/9.2/interactive/app-pgdump.html
-O
--no-owner
Do not output commands to set ownership of objects to match the original
database. By default, pg_dump issues ALTER OWNER or SET SESSION
AUTHORIZATION statements to set ownership of created database objects.
These statements will fail when the script is run unless it is started
by a superuser (or the same user that owns all of the objects in the
script). To make a script that can be restored by any user, but will
give that user ownership of all the objects, specify -O.
This option is only meaningful for the plain-text format. For the
archive formats, you can specify the option when you call pg_restore.
--
Adrian Klaver
adrian(dot)klaver(at)gmail(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Sergey Shelukhin | 2013-09-11 01:02:18 | not aborting transactions on failed select |
Previous Message | Kevin Grittner | 2013-09-10 20:15:27 | Re: Call for design: PostgreSQL mugs |