Re: pg_dumpall won't work?

Поиск
Список
Период
Сортировка
Искать

Re: pg_dumpall won't work?

От:
Tom Lane <tgl@sss.pgh.pa.us>
Дата:
Joel Mc Graw  writes:
> I tried to run pg_dumpall and I got "strdup: failed to allocate
> memory".  I tried to run it again and I get a segmentation fault.

Strange.  Can you provide a debugger backtrace from the segfault?
Another thing that might be useful is to log the queries being sent
to the server, so we can see what the last few were.  Easiest way
to do that is
	export PGOPTIONS="-d2"
(or equivalent for whatever shell you use) before running pg_dump.

			regards, tom lane

pg_dumpall won't work?

От:
Joel Mc Graw <jpmcgraw1@home.com>
Дата:
I tried to run pg_dumpall and I got "strdup: failed to allocate
memory".  I tried to run it again and I get a segmentation fault.  Any
ideas how to back up this (production) database?

PostgreSQL 7.1.3 on FreeBSD 4.2 Release


TIA,

Joel

Re: pg_dumpall won't work?

От:
Tom Lane <tgl@sss.pgh.pa.us>
Дата:
Joel Mc Graw  writes:
> Tom,  I'm afraid I'm not quite the guru I'd like to be; can you (or
> anyone) provide guidance on getting a "debugger backtrace from the
> segfault"? 

Find the core file (if there isn't one, maybe you need "ulimit -c unlimited")
and do
	gdb /path/to/executable /path/to/corefile
	gdb> bt
	gdb> quit
Make sure you are selecting the executable that actually generated the
core dump.  It was less than clear to me from your report whether the
crash was in pg_dumpall, pg_dump (which it invokes), or on the backend
side.  On many platforms file(1) can tell you which program generated
a particular core dump.

BTW, did you say which platform and which PG version this is?

> The following shows the queries after exporting PGOPTIONS="-d2"

No, I meant the queries sent to the backend --- look in the postmaster
log.

			regards, tom lane

Re: pg_dumpall won't work?

От:
Joel Mc Graw <jmcgraw@databill.com>
Дата:


On Thu, 07 Feb 2002 12:52:26 -0500, Tom Lane  wrote:
>Joel Mc Graw  writes:
>> I tried to run pg_dumpall and I got "strdup: failed to allocate
>> memory".  I tried to run it again and I get a segmentation fault.
>
>Strange.  Can you provide a debugger backtrace from the segfault?
>Another thing that might be useful is to log the queries being sent
>to the server, so we can see what the last few were.  Easiest way
>to do that is
>	export PGOPTIONS="-d2"
>(or equivalent for whatever shell you use) before running pg_dump.
>
>			regards, tom lane
>
>---------------------------(end of
broadcast)---------------------------


OK, I finally have a moment to address this (God it's scary having a
production DB and not being able to back it up....)
Tom,  I'm afraid I'm not quite the guru I'd like to be; can you (or
anyone) provide guidance on getting a "debugger backtrace from the
segfault"? 
The following shows the queries after exporting PGOPTIONS="-d2"

-
-- pg_dumpall (7.1.3)
--
\connect template1
DELETE FROM pg_shadow WHERE usesysid <> (SELECT datdba FROM pg_database
WHERE da
tname = 'template0');

CREATE USER "jmcgraw" WITH SYSID 1001 CREATEDB NOCREATEUSER;
CREATE USER "production" WITH SYSID 1002 CREATEDB NOCREATEUSER;
CREATE USER "jbrucker" WITH SYSID 1006 NOCREATEDB NOCREATEUSER;

DELETE FROM pg_group;


--
-- Database production
--
\connect template1 production
CREATE DATABASE "production" WITH TEMPLATE = template0;
\connect production production


TIA for any and all help.





------------------------------------------------------
Joel Mc Graw
DataBill, LLC
602-415-1234 ext. 13

-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS d-@ s: a C++++ UB++++ P-- L- E? W++ N w--- O? M+ V
PS+++ PE++ Y+ PGP++ t+ 5++ X tv+ b+ DI++ G e++ h---- r+++ y++++
-----END GEEK CODE BLOCK-----
FAQ