pg_dump out of memory

[Neil Morgan]

Dear All,

I am running a PostgreSQL 8.3 server (not my choice, would prefer 9.1) but I am experiencing memory issues when using pg_dump.

I have looked on the forums for memory issues, and can say that the data is not corrupt.

We are running a VM with RHEL6, 4GB RAM, 2CPU and 80GB HDD

Does anyone have any ideas please?

pg_type_typname_nsp_index: 3072 total in 2 blocks; 1600 free (2 chunks); 1472 used
pg_operator_oid_index: 3072 total in 2 blocks; 1696 free (2 chunks); 1376 used
pg_amop_opr_fam_index: 3072 total in 2 blocks; 1600 free (2 chunks); 1472 used
pg_proc_oid_index: 3072 total in 2 blocks; 1696 free (2 chunks); 1376 used
pg_opfamily_am_name_nsp_index: 3072 total in 2 blocks; 1624 free (3 chunks); 1448 used
pg_ts_template_oid_index: 3072 total in 2 blocks; 1744 free (3 chunks); 1328 used
MdSmgr: 24576 total in 2 blocks; 6528 free (0 chunks); 18048 used
LOCALLOCK hash: 122880 total in 4 blocks; 38128 free (13 chunks); 84752 used
Timezones: 53584 total in 2 blocks; 3744 free (0 chunks); 49840 used
ErrorContext: 8192 total in 1 blocks; 8160 free (4 chunks); 32 used
ERROR: out of memory
DETAIL: Failed on request of size 1073741823.

Regards,

Neil Morgan PGCert MSc MPhil
IT Services
University of Brighton
Watts 137
Lewes Road
Brighton
BN2 4GJ

01273 643930




___________________________________________________________
This email has been scanned by MessageLabs' Email Security
System on behalf of the University of Brighton.
For more information see http://www.brighton.ac.uk/is/spam/
___________________________________________________________

[Tom Lane]

Post by Neil Morgan
I am running a PostgreSQL 8.3 server (not my choice, would prefer 9.1) but I am experiencing memory issues when using pg_dump.

8.3.what?

Post by Neil Morgan
Does anyone have any ideas please?

For starters, turn on log_statements so you can see what query is
triggering this. It'd be even better if you can get a stack trace
from the point of the errfinish call.
https://wiki.postgresql.org/wiki/Generating_a_stack_trace_of_a_PostgreSQL_backend

regards, tom lane