Tom Lane wrote:
> Another issue is that leftover temp tables would be significantly more
> likely to be self-inconsistent than normal tables, since operations on
> them are not WAL-logged and it's entirely likely that the owning backend
> crashed with some dirty pages not written out from its local buffers.
> AFAICS this shouldn't be any big problem for vacuuming the table proper,
> since heap pages are pretty independent, at least at the level
> understood by plain vacuum.
There's the torn-page problem as well. Highly improbable, but it seems
possible to me to have an inconsistent heap page with for example broken
redirecting line pointers or something like that, that would cause
crashes or assertion failures on vacuum.
> Or we could have autovacuum just drop orphaned temp tables, *if*
> they have gotten old enough to need anti-wraparound vacuuming.
> While I'm still uncomfortable with having autovac drop anything,
> at least this would avoid the worst cases of "gee I really needed
> that data to investigate the crash". The main attractions of this
> idea are avoiding the corrupt-index issue and not doing vacuuming
> work that's 99.99% sure to be useless.
That sounds a lot simpler and better to me.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com