On Tue, Jul 6, 2010 at 9:59 AM, Takahiro Itagaki
wrote:
>
> Tom Lane 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
Tom Lane 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 some
*idle backend
Takahiro Itagaki 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 not reclaimed
> until all
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
