Re: BUG #8612: Truncate did not release disk space
От | Jeff Janes |
---|---|
Тема | Re: BUG #8612: Truncate did not release disk space |
Дата | |
Msg-id | CAMkU=1wzw+_bH7sSUCRJf8g671cO91smhvt_40zCE6bj5bT4+Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #8612: Truncate did not release disk space (Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>) |
Ответы |
Re: BUG #8612: Truncate did not release disk space
|
Список | pgsql-bugs |
On Fri, Nov 22, 2013 at 11:12 AM, Stefan Kaltenbrunner < stefan@kaltenbrunner.cc> wrote: > On 11/20/2013 08:35 PM, eduardoa@mirthcorp.com wrote: > > The following bug has been logged on the website: > > > > Bug reference: 8612 > > Logged by: Eduardo Armendariz > > Email address: eduardoa@mirthcorp.com > > PostgreSQL version: 9.0.13 > > Operating system: CentOS > > Description: > > > > Ran out of disk space and postgres shut down. Recovered enough disk space > > for database to be operational. Truncated the largest table in the > database, > > the message table. This table had over 600gb of data. The result of the > > truncate was that only about 200gb of the data was actually released to > the > > OS. > > sure that no other backend was/is actually still a file-handle > referenced? That open filehandle will prevent the OS from showing up the > freed space on the filesystem and can happen if you have backends still > running that once referenced the table now truncated and have not done > any work since you did the truncate (like a large connection pool or > idle client connections, maybe an open psql session or something like > that). > If that were the case, I don't think pg_database_size would still be counting the size, as it would no longer be able to find it the files in that directory. I think the next step would be to get an 'ls -l' listing of the $PGDATA/base/<dboid> directory. Cheers, Jeff
В списке pgsql-bugs по дате отправления: