Re: help getting a backtrace from 9.2 on Ubuntu 13.04?

On 09/10/2013 06:57 AM, Chris Curvey wrote:
> *From:*Marcin Mańk [mailto:marcin(dot)mank(at)gmail(dot)com]
> *Sent:* Monday, September 09, 2013 8:30 PM
> *To:* Chris Curvey
> *Cc:* pgsql-general(at)postgresql(dot)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(at)zuckergoldberg(dot)com
> <mailto:ccurvey(at)zuckergoldberg(dot)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(at)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(dot)klaver(at)gmail(dot)com