pg_dump core dumping

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