On 5/27/07, Robert Treat <[EMAIL PROTECTED]> 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:
> > > --On Freitag, Mai 25, 2007 10:49:29 +0000 Jaime Casanova
> > >
> > > <[EMAIL PROTECTED]> wrote:
> > >> 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.
> ah, i forgot that
> > 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.
> 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
i don't think silently delete the files is a good idea, specially if
the files are left there intencionally...
but what, exactly, we want to do? delete the files or maybe sending an
HINT just after the error so we can inform the DBA about the temp
files and let him decide.
BTW, postmaster startup is in PgStartTime, right?
"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs and the universe trying
to produce bigger and better idiots.
So far, the universe is winning."
---------------------------(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