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

Re: Vacuuming leaked temp tables (once again)

From: Stephen Frost <sfrost(at)snowman(dot)net>
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:36:56
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)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.



In response to


pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2008-06-27 16:43:09
Subject: Re: Vacuuming leaked temp tables (once again)
Previous:From: Tom LaneDate: 2008-06-27 16:35:16
Subject: Re: Vacuuming leaked temp tables (once again)

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