Re: help getting a backtrace from 9.2 on Ubuntu 13.04? - Mailing list pgsql-general

On 09/10/2013 06:57 AM, Chris Curvey wrote:
> *From:*Marcin Mańk [mailto:marcin.mank@gmail.com]
> *Sent:* Monday, September 09, 2013 8:30 PM
> *To:* Chris Curvey
> *Cc:* pgsql-general@postgresql.org
> *Subject:* Re: [GENERAL] help getting a backtrace from 9.2 on Ubuntu 13.04?
>
> On Mon, Sep 9, 2013 at 4:00 PM, Chris Curvey <ccurvey@zuckergoldberg.com
> <mailto:ccurvey@zuckergoldberg.com>> wrote:
>
>     But I'm having troubles with the 9.2 server crashing when I'm
>     restoring the dump.  I'm using the 9.2 version of pg_dump.  I've
>     tried restoring a custom-format dump with pg_restore, and I've tried
>     restoring  a text-format dump with pqsl, and both of them are
>     crashing on me.
>
>     The data is too sensitive for me to submit a database dump to the
>     community, but I'd like to submit a stack trace, in the hopes that
>     someone might be able to figure out what's going on.  But I'm having
>     some trouble getting this done.
>
> Is it crashing on a specific database object? pg_restore -v will tell
> you how far it went. Then try to restore only that object. Is it perhaps
> crashing on a specific row?
>
> Try producing a self contained test case (like only the culprit table,
> anonymized).
>
> Regards
>
> Marcin Mańk
>
> Good advice.  I turned on –verbose, and got a ton of output, ending with:
>
> pg_restore: setting owner and privileges for FK CONSTRAINT
> user_id_refs_id_7ceef80f
>
> pg_restore: setting owner and privileges for FK CONSTRAINT
> user_id_refs_id_dfbab7d
>
> pg_restore: [archiver (db)] could not execute query: no connection to
> the server
>
>      Command was: -- Completed on 2013-09-09 11:35:16 EDT
>
> pg_restore: [archiver (db)] could not execute query: no connection to
> the server


At this point I would be more worried about the above, 'no connection to
server'.

>
>      Command was: --
>
> -- PostgreSQL database dump complete
>
> –
>
> Which I find really odd, because I specified –no-owner –no-privileges
> –no-tablespace

--no-owner does not mean that ownership is not set, just that the
ownership from the source database is not carried over.

http://www.postgresql.org/docs/9.2/interactive/app-pgrestore.html

-O
--no-owner
Do not output commands to set ownership of objects to match the original
database. By default, pg_restore issues ALTER OWNER or SET SESSION
AUTHORIZATION statements to set ownership of created schema elements.
These statements will fail unless the initial connection to the database
is made by a superuser (or the same user that owns all of the objects in
the script). With -O, any user name can be used for the initial
connection, and this user will own all the created objects.

>
> chris@mu:/sdb$ pg_restore --dbname=certified_mail_ccc2 --format=c
> --verbose --clean --no-owner --no-privileges --no-tablespaces -h mu -p
> 5434 cm_Mon.backup
>
> So now I’m up to three questions.  (Why the crash?  How to get
> backtrace?  Why are we applying permissions when I said not to?)  I
> guess that’s the nature of the universe. Let me see if I can figure out
> which table that is and try to create a test case.
>
>


--
Adrian Klaver
adrian.klaver@gmail.com