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 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 of the backends close their file descriptors. Longer checkpoint timeout and connection pooling make things worse. I'd like to suggest that we always truncate any segments before unlink them. The truncate-and-unlink hack seems to be developed to avoid reuse of relfilenode: | Leaving the empty file in place prevents that relfilenode | number from being reused. but is also useful to release disk spaces in the early stages. Am I missing something? Comments welcome. Regards, --- Takahiro Itagaki NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
