Обсуждение: pg_dump out of memory
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/
___________________________________________________________
Neil Morgan <N.A.Morgan@brighton.ac.uk> writes: > 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? > 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