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

Re: Always truncate segments before unlink

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Takahiro Itagaki <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Always truncate segments before unlink
Date: 2010-07-05 14:33:47
Message-ID: 430.1278340427@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Takahiro Itagaki <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)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 not reclaimed
> until all of the backends close their file descriptors. Longer
> checkpoint timeout and connection pooling make things worse.

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.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Robert HaasDate: 2010-07-05 14:47:57
Subject: logistics for beta3
Previous:From: Greg SmithDate: 2010-07-05 14:05:38
Subject: Re: Table partitioning - is anything coming?

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