From: | Kevin Grittner <kgrittn(at)ymail(dot)com> |
---|---|
To: | Vincent de Phily <vincent(dot)dephily(at)mobile-devices(dot)fr>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Deleted files still open long after droping a database |
Date: | 2014-02-18 01:36:01 |
Message-ID: | 1392687361.55264.YahooMailNeo@web122302.mail.ne1.yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Vincent de Phily <vincent(dot)dephily(at)mobile-devices(dot)fr> wrote:
> I have droped a database a few hours ago to reclaim some badly-needed space,
> but that disk space has not been freed yet. Investigating further, there are
> lots of deleted but open files that seem to correspond to the droped db, all
> open by some postgres process.
>
> A lot of process were db connections to databases other than the droped one
> (I'm not using connection pooling). The other process is the autovacuum
> launcher. I have reset the various connection processes, but I hesitate to
> kill the autovacuum process.
>
> I'm not sure wether that's relevant, but I moved the database to another
>
> server using slony1-2.2.2 before droping it on the old server. There were
> already no more slon processes running when I droped the db.
>
>
> 1) why does this happen at all (keeping files from a droped databse open, even
> by processes that never connected to that specific db) ?
>
> 2) Can the autovacuum launcher process be safely killed (there are no long-
> running vacuum queries) ?
>
> 3) Is there a generally cleaner way to do all this ?
I suspect that the other backends needed to flush a page from cache
to free space for a page they wanted to use, and the file was not
closed in case the same backend needed to flush other pages from
the same file.
Perhaps we should arrange for a DROP DATABASE command to somehow
signal all backends to close files from that backend? Or they
should periodically check?
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Janes | 2014-02-18 01:45:23 | Re: avoiding file system caching of a table |
Previous Message | Gabriel E. Sánchez Martínez | 2014-02-18 01:09:52 | Re: avoiding file system caching of a table |