Jeff Gold <jgold@xxxxxxxxxxxxxxxx> 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 ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
