Skip site navigation (1) Skip section navigation (2)

Re: Vacuuming leaked temp tables (once again)

From: "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: Vacuuming leaked temp tables (once again)
Date: 2008-06-27 16:24:41
Message-ID: 48651449.2060306@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-hackers
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

In response to

Responses

pgsql-hackers by date

Next:From: Hiroshi SaitoDate: 2008-06-27 16:33:03
Subject: Re: MSVC 2003 compile error with pg8.3.3
Previous:From: Gregory StarkDate: 2008-06-27 16:12:20
Subject: Re: Vacuuming leaked temp tables (once again)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group