Excerpts from Alexander Shulgin's message of vie jun 03 17:45:28 -0400 2011:
> There were about 450 such (or similar) files, all of them having /2613 in the > filename. Since 2613 is a regclass of pg_largeobject and we are indeed > working with quite a few large objects in that DB so this is where our > problem lies we suspect. > > Restarting PostgreSQL obviously helps the issue and the disk space occupied > by those unlinked files (about 63GB actually) is reclaimed. > > So what happens on that host is that we drop/restore a fresh version of the > DB from the production host, followed by a migration script which among other > things loads around 16GB of data files as large objects. This happens > nightly. What surprises me is that the open references remain after a database drop. Surely this means that no backends keep open file descriptors to any table in that database, because there are no connections. I also requested Alexander to run a checkpoint and see if that made the FDs go away (on the theory that bgwriter could be the culprit) -- no dice. -- Álvaro Herrera <alvhe...@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
