Thread: pg_dump core dumping
Hi All, Got a weird issue that I'm running into when attempting to dump a database under PostgreSQL 7.2.4. The OS is FreeBSD 4.8, with ~100 GBytes RAID and 4 Gig's of RAM. The pg_dump command is: pg_dump -U pgsql -S pgsql -D -F p -f test.sql test When I try to dump the database, she appears to follow through fine, and top show's that she get's up to about 512 MBytes of RAM in use then core dumps. the output file (test.sql) is never even written to, however the ~512 MByte core file is left behind (obviously :>). One thing that has be curious, is why the system is even loading up that much RAM, as the database itself is only ~46 MBytes: test# du -skc 16717879 46300 16717879 46300 total The system has loaded of free disk space , and the user (root) has permissions to write to the folder I'm dumping the file to. Here is a back trace of the core file, as this is my first report to the bugs list, let me know if there is anything else I can send that might help. (gdb) bt #0 0x280880ac in getRowDescriptions (conn=0x8068200) at fe-exec.c:1027 #1 0x28087eaa in parseInput (conn=0x8068200) at fe-exec.c:919 #2 0x28088525 in PQgetResult (conn=0x8068200) at fe-exec.c:1249 #3 0x280886b9 in PQexec (conn=0x8068200, query=0x8076600 "SELECT adsrc from pg_attrdef where adrelid = '16721225'::oid and adnum = 8 ") at fe-exec.c:1362 #4 0x804ee92 in getTableAttrs () #5 0x80530fa in dumpSchema () #6 0x804af64 in main () #7 0x8049b4a in _start (arguments=0x7fbffc90 "/vm/.t/usr/ports/local/postgresql-7.2.4/src/bin/pg_dump/pg_dump") at /usr/src/lib/csu/i386-elf/crt1.c:119 -- Chris Bowlby <excalibur@hub.org> Hub.Org Networking Services
Chris Bowlby <excalibur@hub.org> writes:
> (gdb) bt
> #0 0x280880ac in getRowDescriptions (conn=0x8068200) at fe-exec.c:1027
> #1 0x28087eaa in parseInput (conn=0x8068200) at fe-exec.c:919
> #2 0x28088525 in PQgetResult (conn=0x8068200) at fe-exec.c:1249
> #3 0x280886b9 in PQexec (conn=0x8068200, query=0x8076600 "SELECT adsrc
> from pg_attrdef where adrelid = '16721225'::oid and adnum = 8 ") at
> fe-exec.c:1362
Bizarre. What happens if you try that same SELECT from psql? (I'd sort
of expect psql to blow up too, but it'd be worth confirming.) How about
variants such as "SELECT length(adsrc) FROM ..." ? Can you do a \d on
whichever table has OID 16721225?
I'm guessing that that row of pg_attrdef is somehow corrupt, but why the
corruption would crash the client rather than the backend escapes me ...
regards, tom lane
On Sat, 2003-04-26 at 13:52, Tom Lane wrote: Ok, running the select statement that was used in the core file, I get these results: test=# SELECT adsrc from pg_attrdef where adrelid = '16721225'::oid and adnum = 8 ; adsrc ------- 'f' (1 row) The table with OID 16721225 seems to work with out issue as well: test=# select * from ec_picklist_items_audit; picklist_item_id | picklist_item | picklist_name | sort_key | last_modified | last_modifying_user | modified_ip_address | delete_p ------------------+---------------+---------------+----------+---------------+---------------------+---------------------+---------- (0 rows) > Chris Bowlby <excalibur@hub.org> writes: > > (gdb) bt > > #0 0x280880ac in getRowDescriptions (conn=0x8068200) at fe-exec.c:1027 > > #1 0x28087eaa in parseInput (conn=0x8068200) at fe-exec.c:919 > > #2 0x28088525 in PQgetResult (conn=0x8068200) at fe-exec.c:1249 > > #3 0x280886b9 in PQexec (conn=0x8068200, query=0x8076600 "SELECT adsrc > > from pg_attrdef where adrelid = '16721225'::oid and adnum = 8 ") at > > fe-exec.c:1362 > > Bizarre. What happens if you try that same SELECT from psql? (I'd sort > of expect psql to blow up too, but it'd be worth confirming.) How about > variants such as "SELECT length(adsrc) FROM ..." ? Can you do a \d on > whichever table has OID 16721225? > > I'm guessing that that row of pg_attrdef is somehow corrupt, but why the > corruption would crash the client rather than the backend escapes me ... > > regards, tom lane -- Chris Bowlby <excalibur@hub.org> Hub.Org Networking Services
Chris Bowlby <excalibur@hub.org> writes:
> Ok, running the select statement that was used in the core file, I get
> [ normal results ]
Okay, scratch that theory. Looking at it a second time, I now think
this particular select is not directly at fault, but is simply losing
because pg_dump is out of memory (a condition libpq has never tolerated
very well :-(). But that still leaves us with the question of where the
memory went. The stack trace shows that pg_dump is still collecting
schema information, and hasn't begun pulling down the contents of user
tables --- but how could it chew up 512Mb on schema information?
I would suggest turning on query logging (look in postgresql.conf) and
re-running pg_dump. Perhaps a look at the series of queries it issues
will show that it's gotten stuck in a loop somewhere.
Another test that would be useful, if you happen to have a 7.3
installation handy, is to see if 7.3 pg_dump can dump this database.
regards, tom lane
On Sat, 2003-04-26 at 15:02, Tom Lane wrote: Hi Tom, PostgreSQL 7.3.2's pg_dump utility was able to completely dump out the schema with out core dumping, and the queries that were being output to the log file were very different from those used by PostgreSQL 7.2.4's pg_dump utility. v7.2 seemed to get past the schema checks and was doing queries on the data in the tables, but then it just quite litterally puttered out... :> > Chris Bowlby <excalibur@hub.org> writes: > > Ok, running the select statement that was used in the core file, I get > > [ normal results ] > > Okay, scratch that theory. Looking at it a second time, I now think > this particular select is not directly at fault, but is simply losing > because pg_dump is out of memory (a condition libpq has never tolerated > very well :-(). But that still leaves us with the question of where the > memory went. The stack trace shows that pg_dump is still collecting > schema information, and hasn't begun pulling down the contents of user > tables --- but how could it chew up 512Mb on schema information? > > I would suggest turning on query logging (look in postgresql.conf) and > re-running pg_dump. Perhaps a look at the series of queries it issues > will show that it's gotten stuck in a loop somewhere. > > Another test that would be useful, if you happen to have a 7.3 > installation handy, is to see if 7.3 pg_dump can dump this database. > > regards, tom lane -- Chris Bowlby <excalibur@hub.org> Hub.Org Networking Services
Chris Bowlby <excalibur@hub.org> writes:
> PostgreSQL 7.3.2's pg_dump utility was able to completely dump out the
> schema with out core dumping,
Hm. Well, if you're doing this in order to update to 7.3, then it's
probably not worth digging deeper --- the 7.3 dump file is what you want
anyway. Otherwise we need to look for some memory leak that was fixed
between 7.2 and 7.3 ...
regards, tom lane