Jeff Gold <jgold@mazunetworks.com> writes:
> About once per week the
> database enters some pathological state where the parent postmaster --
> NOT one of the child connections -- appears to run out of memory.
I can absolutely, positively say that that dump is not from the parent
postmaster. It's a backend. Apparently it's a backend that is creating
an unreasonable number of hashtables --- the default location for
hashtable overhead is TopMemoryContext, and it looks like that explains
this:
> TopMemoryContext: 87552048 total in 10683 blocks; 181280 free (60
> chunks); 87370768 used
However this is a bit odd:
> CacheMemoryContext: 421519360 total in 60 blocks; 830096 free (457
> chunks); 420689264 used
I can't really think what would blow out CacheMemoryContext like that.
> pg_temp_260196: 1024 total in 1 blocks; 640 free (0 chunks); 384 used
> pg_toast_888382258_index: 1024 total in 1 blocks; 320 free (0 chunks);
> 704 used
> pg_toast_888382258_index: 1024 total in 1 blocks; 320 free (0 chunks);
> 704 used
> [...]
> DynaHashTable: 0 total in 0 blocks; 0 free (0 chunks); 0 used
> DynaHashTable: 0 total in 0 blocks; 0 free (0 chunks); 0 used
> DynaHashTable: 0 total in 0 blocks; 0 free (0 chunks); 0 used
> DynaHashTable: 0 total in 0 blocks; 0 free (0 chunks); 0 used
> DynaHashTable: 0 total in 0 blocks; 0 free (0 chunks); 0 used
This is quite uninformative. Are you suggesting that there are many
many lines about indexes? Many many lines about DynaHashTable? Both?
How many tables/indexes do you have in your database, anyway? Could
this process be running pg_dump, or something else that would try to
touch them all?
regards, tom lane