On 11/22/10, Tom Lane <t...@sss.pgh.pa.us> wrote: > Jon Nelson <jnelson+pg...@jamponi.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. Thanks! -- Jon -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
