Re: Disk filled-up issue after a lot of inserts and drop schema

Thank you guys.
I’ve jsut discovered the issue.. I set "logging_collector=off” in the previous email but didn’t comment the other log*
parameters,so Postgres was logging every single INSERT! This was caused the disk to fill up. 

The strange issue is that the log file didn’t exists when the disk filled up. I personally looked for it but it wasn’t
whereit should have been ( /var/log/postgesql/ ), so I can’t exactly confirm that the issue was the log file getting
biggerand bigger. 

Now, after writing the previous mail and rebooting postgres, I run several ETL jobs and the disk space was filling up.
Thelog file reached 110GB in size. 
After disabling *ALL* the log options in postgresql.conf, the log file does just the essential and default information.


I’m sorry to have launched a false alarm, but we can consider the issue solved.

Thank you again

Best regards,
 Pietro Pugni




> Il giorno 14 set 2016, alle ore 16:44, Tom Lane <tgl@sss.pgh.pa.us> ha scritto:
>
> Rick Otten <rottenwindfish@gmail.com> writes:
>> I don't know why something still has an open file descriptor on something
>> you believe has been removed, but at least that explains why you are
>> experiencing the discrepancy between "du" and the real available space on
>> the disk.
>
> Yeah, the reported behavior clearly indicates that some PG process is
> holding open files that should have been dropped (and were unlinked).
> That's a bug, but there's not enough info here to find and fix it.
>
> If we're really lucky, this is the same bug that Andres found and fixed
> last week:
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=26ce63ce76f91eac7570fcb893321ed0233d62ff
>
> but that guess is probably too optimistic, especially if it's a background
> process (such as the checkpointer process) that is holding the open files.
>
> If you can reproduce this, which I'm guessing you can, please use
> "lsof" or similar tool to see which Postgres process is holding open
> references to lots of no-longer-there files.
>
>             regards, tom lane