On May 27, 2012, at 12:53 PM, Tom Lane wrote: > Another thing that can be deduced from those stack traces is that sinval > resets were happening. For example, in the third message linked above, > the heapscan is being done to load up a relcache entry for relation 2601 > (pg_am). This would be unsurprising, except that stack frames 17 and 18 > show this is happening during the fifth call of load_critical_index, and > we should have had both pg_am's reldesc and the syscache entry that's > being fetched at relcache.c:1010 loaded up in the first call. So those > cache entries have to have gotten blown away by sinval reset. This is > not terribly surprising if there were a steady flux of DDL happening in > the database, for instance temp table creations/drops. (Jeff, can you > comment on that?) If heapscans over the whole of pg_attribute were > occurring, they'd take long enough to expose the process to sinval > overrun even with not-very-high DDL rates.
As it turns out, there are quite a few temporary tables created. During the busiest periods of the day, this system averages 1.75 temp tables per second.
