Skip site navigation (1) Skip section navigation (2)

Always truncate segments before unlink

From: Takahiro Itagaki <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Always truncate segments before unlink
Date: 2010-07-05 02:23:52
Message-ID: 20100705112352.9462.52131E4D@oss.ntt.co.jp (view raw or flat)
Thread:
Lists: pgsql-hackers
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


Responses

pgsql-hackers by date

Next:From: Pavel StehuleDate: 2010-07-05 03:31:34
Subject: Re: proof concept: do statement parametrization
Previous:From: Florian PflugDate: 2010-07-04 23:30:01
Subject: Re: proof concept: do statement parametrization

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group