Horton

Re: Postmaster holding unlinked files for pg_largeobject table

Alvaro Herrera <alvherre@commandprompt.com>

View thread
From: Alvaro Herrera <alvherre@commandprompt.com>
To: Alexander Shulgin <ash@commandprompt.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>, alexk <alexk@commandprompt.com>
Date: 2011-06-04T01:32:56Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Reset reindex-in-progress state before reverifying an exclusion constraint.

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 <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support