On 11/22/10, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Jon Nelson <jnelson+pgsql(at)jamponi(dot)net> writes:
>> Here is the problem: When I started benchmarking this application, I
>> noticed it (postgresql) started chewing up inodes on the logical
>> volume which houses /var/lib/pgsql. It chewed up a few thousand
>> inodes, and then a few thousand more, and then there were no more.
>> I investigated /var/lib/pgsql/data/ and found within the database's
>> directory many thousands of 0-byte files. I stopped the application
>> expecting at the end of a /session/ that the inodes would be unlinked,
>> but there was no change. lsof told me nobody had them open. However, a
>> start/stop of postgresql removed (at least most of) the 0-byte files.
>> After some trial and error, I straced the right process (the bgwriter
>> process) and found that, upon signal to leave, it would write some
>> checkpoint-y stuff and then proceed about unlinking most or all of the
>> 0-byte files.
> This is not a bug; it's normal behavior when dropping a table. The
> table file is truncated to zero bytes at commit, but it's not unlinked
> until the next checkpoint. I surmise that you may have a very long
> checkpoint cycle time selected.
Indeed I do. An explicit CHECKPOINT also clears the inodes up.
I was very surprised to chew threw some 16 thousand inodes in a minute or two.
In response to
pgsql-bugs by date
|Next:||From: Tom Lane||Date: 2010-11-23 15:29:43|
|Subject: Re: BUG #5763: pg_hba.conf not honored |
|Previous:||From: Kaiting Chen||Date: 2010-11-23 08:34:19|
|Subject: BUG #5763: pg_hba.conf not honored|