Re: Reviewing temp_tablespaces GUC patch - Mailing list pgsql-hackers

From Robert Treat
Subject Re: Reviewing temp_tablespaces GUC patch
Date
Msg-id 200705271419.49384.xzilla@users.sourceforge.net
Whole thread Raw
In response to Re: Reviewing temp_tablespaces GUC patch  ("Jaime Casanova" <systemguards@gmail.com>)
Responses Re: Reviewing temp_tablespaces GUC patch
Re: Reviewing temp_tablespaces GUC patch
List pgsql-hackers
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:
> > > --On Freitag, Mai 25, 2007 10:49:29 +0000 Jaime Casanova
> > >
> > > <systemguards@gmail.com> 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 
tablespace itself?  

-- 
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: buildfarm failures after pgstat patch
Next
From: Oleg Bartunov
Date:
Subject: Re: Why not keeping positions in GIN?