Re: Postmaster Out of Memory

Jeff Gold <jgold(at)mazunetworks(dot)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