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 <tgl@sss.pgh.pa.us> wrote:
>>> Bernd Helmle <mailings@oopsware.de> 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 jim@nasby.net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
