From: Christoph Berg <myon@debian.org>
To: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: Monitoring disk space from within the server
Date: Fri, 8 Nov 2019 16:06:21 +0100
Message-ID: <20191108150621.GL8017@msg.df7cb.de> (raw)
In-Reply-To: <20191108145025.d7pfcip6plufxiah@development>
References: <20191108132419.GG8017@msg.df7cb.de>
<20191108145025.d7pfcip6plufxiah@development>
Re: Tomas Vondra 2019-11-08 <20191108145025.d7pfcip6plufxiah@development>
> While I agree monitoring disk space is important, I think pretty much
> every deployment already does that using some other monitoring tool
> (which also monitors million other things).
There are plenty of deployments where that isn't true, either because
they aren't doing any monitoring, or (probably more commonly) because
the OS monitoring is done by the OS department and the DB department
doesn't have good access to the figures, and possibly not even any
shell access.
Offering the numbers on the database level would make monitoring
easier for these users, and also provide the numbers on the level
where they might be useful. ("Do I have enough disk space to load this
5GB dump now?")
> Also, I wonder how universal / reliable this actually is, considering
> the range of filesystems and related stuff (thin provisioning, quotas,
> ...) people use in production. I do recall a number of cases when "df"
> was showing a plenty of free space, but one of the internal resources
> for that particular filesystem was exhausted. I doubt it's desirable to
> add all this knowledge into PostgreSQL.
That might be partly true, e.g. btrfs traditionally didn't support
"df" but only "btrfs df". But this got fixed in the meantime, and just
because there are weird filesystems doesn't mean we shouldn't try to
support the normal case where statfs() just works.
> It's not clear to me what issue this is actually meant to solve - it
> provides data, which is nice, but it still needs to be fed to some
> motinoring and alerting system. And every monitoring system has a good
> plugin to collect this type of data, so why not to use that?
What's wrong with providing nice data? It doesn't hurt to have it.
And the cost of the implementation is low.
> Surely, we can't rely on this for any internal logic - so why not to
> provide this as an extension?
By the same argument you could also argue that \l+ should be an
extension because database size is optional to know.
I think this should be directly in core because it's useful to a wide
range of users.
Christoph
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-hackers@postgresql.org
Cc: myon@debian.org, tomas.vondra@2ndquadrant.com
Subject: Re: Monitoring disk space from within the server
In-Reply-To: <20191108150621.GL8017@msg.df7cb.de>
* 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