Re: BUG #17449: Disk space not released - Mailing list pgsql-bugs

From Giorgio Saviane
Subject Re: BUG #17449: Disk space not released
Date
Msg-id CAHs6c0fkZysJ+TgnScf0YWXLDqcXD58NFUUPAr09n4o3DsSvEg@mail.gmail.com
Whole thread Raw
In response to Re: BUG #17449: Disk space not released  (Jeff Janes <jeff.janes@gmail.com>)
Responses Re: BUG #17449: Disk space not released
List pgsql-bugs
>>
>> >>>
>> >>> > Despite any attempt
>> >>> > of full vacuum the discrepancy remained the same. I suspect that Postgres
>> >>> > started leaking disk space. I could see many 1Gb files with a timestamp of
>> >>> > two months back in time in the postgres data folder.
>> >
>> >
>> > If the database suffers a crash (or immediate shutdown) in the middle of something like VACUUM FULL or CLUSTER, it
mightleave orphaned in-process files such as the ones you describe behind and have no way to know to clean them up.
Theknowledge about what it was working on just before the crash was lost in the crash. 
>> >
>> > Files not touched in 2 months and also not referenced in pg_class.relfilenode are almost certainly such orphaned
filesand could, with extreme nervousness, be cleaned up by hand.  Especially if the human-readable log files support a
crashhaving happened at that time. 
>>
>> That was not the case. The server has been running seamlessly since I
>> rebuilt the master.
>
>
> But as i understand it, you rebuilt the master as a response to the problem, so the time period in question is before
therebuild, not after. 
>

Yes, but then after the master was rebuilt it happened that the master
started logging "requested WAL segment XXX has already been removed"
again.

Kind regards

Giorgio



pgsql-bugs by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: BUG #17485: Records missing from Primary Key index when doing REINDEX INDEX CONCURRENTLY
Next
From: Gregory Jensen
Date:
Subject: Inconsistent time zone output for JSON at UTC