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

Re: temporary tables, and lots of 0 byte files

From: Jon Nelson <jnelson+pgsql(at)jamponi(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: temporary tables, and lots of 0 byte files
Date: 2010-11-23 14:37:02
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
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 LaneDate: 2010-11-23 15:29:43
Subject: Re: BUG #5763: pg_hba.conf not honored
Previous:From: Kaiting ChenDate: 2010-11-23 08:34:19
Subject: BUG #5763: pg_hba.conf not honored

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