On May 27, 2007, at 1:19 PM, Robert Treat wrote:
On Friday 25 May 2007 12:39, Jaime Casanova wrote:
On 5/25/07, Tom Lane <[EMAIL PROTECTED]> wrote:
Bernd Helmle <[EMAIL PROTECTED]> writes:
No, because the RemovePgTempFiles() call in PostmasterMain() will
remove all tmp files at startup.
I believe we do not call RemovePgTempFiles during a crash recovery
cycle; this is intentional on the theory that the temp files might
contain useful debugging clues.
So there is a potential problem there.
Not sure how important it really is though --- neither crashes nor
tablespace drops ought to be so common that we need a really nice
solution.
While tablespace operations won't normally be a day-to-day thing,
it's not good if users can't delete a tablespace because it's not
empty, but can't find out what exactly is in the tablespace.
the only semi-sane solution i can think of, is to have a superuser
only function that acts as a wrapper for RemovePgTempFiles(), but
still exists a chance for shoot yourself on the foot...
If there was a way for DBA's to know they could safely delete the
left-over
files (maybe the files timestamp is older than postmaster start;
though not
sure how you measure that), then I think this would be enough to
give them a
way out. Of course maybe that level of smarts could be put into drop
tablespace itself?
If we're saving data on crashes with the intention that it might be
useful then we need to be able to get a list of what those files are,
and possibly be able to delete them easily.
--
Jim Nasby [EMAIL PROTECTED]
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
