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
