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.