From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bernd Helmle <mailings(at)oopsware(dot)de> |
Cc: | Jaime Casanova <systemguards(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Reviewing temp_tablespaces GUC patch |
Date: | 2007-05-25 15:58:11 |
Message-ID: | 10757.1180108691@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bernd Helmle <mailings(at)oopsware(dot)de> writes:
> --On Freitag, Mai 25, 2007 10:49:29 +0000 Jaime Casanova
> <systemguards(at)gmail(dot)com> wrote:
>> No, because the RemovePgTempFiles() call in PostmasterMain() will
>> remove all tmp files at startup.
> Hmm isn't RemovePgTempFiles() called on postmaster startup only? What will
> happen if a temp tablespace is out of disk space, and the backend leaves
> all previously created temp files there? Under these assumption we'll need
> to restart the postmaster to get a clean tablespace ready to drop...
Theoretically, a backend will always remove its temp files during
transaction abort, so the only case that is really of concern is a
backend crashing before it can get around to doing that. However, 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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bernd Helmle | 2007-05-25 16:02:26 | Re: Reviewing temp_tablespaces GUC patch |
Previous Message | Bernd Helmle | 2007-05-25 15:30:27 | Re: Reviewing temp_tablespaces GUC patch |