Re: Backends stalled in 'startup' state: index corruption

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.