From: Pietro Pugni <pietro.pugni@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Rick Otten <rottenwindfish@gmail.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: Disk filled-up issue after a lot of inserts and drop schema
Date: Wed, 14 Sep 2016 19:45:34 +0200
Message-ID: <FE960B29-7786-4A97-9288-4346F48A21A7@gmail.com> (raw)
In-Reply-To: <28460.1473864279@sss.pgh.pa.us>
References: <AEA46136-0A29-4F3C-8966-90178EE44B4B@gmail.com>
<CAMAYy4K6nwkqqdRcWR4cNeYvCXAH7h4WAo6vq1AkX3+MYOezsw@mail.gmail.com>
<28460.1473864279@sss.pgh.pa.us>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-performance>
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 where it should have been ( /var/log/postgesql/ ), so I can’t exactly confirm that the issue was the log file getting bigger and bigger.
Now, after writing the previous mail and rebooting postgres, I run several ETL jobs and the disk space was filling up. The log 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=26ce63ce76f91eac7570fcb893321ed02...
>
> 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
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: pietro.pugni@gmail.com, tgl@sss.pgh.pa.us, rottenwindfish@gmail.com
Subject: Re: Disk filled-up issue after a lot of inserts and drop schema
In-Reply-To: <FE960B29-7786-4A97-9288-4346F48A21A7@gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox