On Tue, Jul 6, 2010 at 9:59 AM, Takahiro Itagaki
itagaki.takah...@oss.ntt.co.jp wrote:
Tom Lane t...@sss.pgh.pa.us wrote:
Truncating seems like an ugly kluge that's not fixing the real problem.
Why are there open descriptors for a dropped relation? They should all
get closed as a consequence
Takahiro Itagaki itagaki.takah...@oss.ntt.co.jp writes:
In mdunlink(), we truncate the first main fork to zero length
and actually unlink at the next checkpoint, but other segments
are not truncated and only unlinked. Then, if another backend
open the segments, disk spaces occupied by them are
Tom Lane t...@sss.pgh.pa.us wrote:
Truncating seems like an ugly kluge that's not fixing the real problem.
Why are there open descriptors for a dropped relation? They should all
get closed as a consequence of relcache flush.
Relcache will be flushed at the next command, but there could be
I have a report from an user that postgres server gave up REINDEX
commands on the almost-disk-full machine. The disk spaces were
filled with old index segments, that should be replaced with
re-constructed files made by the REINDEX.
In mdunlink(), we truncate the first main fork to zero length
and
