Re: Reviewing temp_tablespaces GUC patch
От | Robert Treat |
---|---|
Тема | Re: Reviewing temp_tablespaces GUC patch |
Дата | |
Msg-id | 200705271419.49384.xzilla@users.sourceforge.net обсуждение исходный текст |
Ответ на | Re: Reviewing temp_tablespaces GUC patch ("Jaime Casanova" <systemguards@gmail.com>) |
Ответы |
Re: Reviewing temp_tablespaces GUC patch
Re: Reviewing temp_tablespaces GUC patch |
Список | 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 по дате отправления: