Re: Vacuuming leaked temp tables (once again) - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: Vacuuming leaked temp tables (once again)
Date
Msg-id 20080627163656.GG31154@tamriel.snowman.net
Whole thread Raw
In response to Vacuuming leaked temp tables (once again)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Vacuuming leaked temp tables (once again)  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Vacuuming leaked temp tables (once again)  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-hackers
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> The only solution proposed in that thread was to auto-delete temp
> tables at postmaster restart; which I opposed on the grounds that
> throwing away data right after a crash was a terrible idea from a
> forensic standpoint.

Why not just rename the files out of the way, and nuke the entries from
the catalog?  Something like "filename.crash" or similar that an admin
can have scripts in place to check for and who could then go handle as
appropriate (remove, investigate, etc).  If there's data in the catalog
that you think might be bad to lose, then include it in some kind of
format in a "filename.crash.catalog" or similar file.  Maybe also spit
out a warning or error or something on backend start when this rename is
done, and on subsequent starts if the file remains.

What I really don't like is keeping something that is likely useless and
possibly deadly to a backend if corrupt & accessed sitting around.  I'm
also not a big fan of keeping what is essentially 'garbage' around in
the catalog which could just lead to confusion later if someone's
looking at "what actual temporary tables should there be" and seeing
others that they wouldn't expect.
Thanks,
    Stephen

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Vacuuming leaked temp tables (once again)
Next
From: Tom Lane
Date:
Subject: Re: Vacuuming leaked temp tables (once again)