Re: Monitoring disk space from within the server

From: Julien Rouhaud <rjuju123(at)gmail(dot)com>
To: Christoph Berg <myon(at)debian(dot)org>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Monitoring disk space from within the server
Date: 2019-11-08 13:32:13
Message-ID: CAOBaU_YVGEnsnP1ufp42NiJ+WvPHRWBOsBOcaxWxsbXPN_sdNQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Nov 8, 2019 at 2:24 PM Christoph Berg <myon(at)debian(dot)org> wrote:
>
> Monitoring the available disk space is the topmost thing on the
> priority for PostgreSQL operation, yet this metric is not available
> from the SQL level.
>
> The attached patch implements a function pg_tablespace_statfs(tblspc)
> to report disk space numbers per tablespace:
>
> # select * from pg_tablespace_statfs('pg_default');
> blocks │ bfree │ bavail │ files │ ffree
> ───────────┼──────────┼──────────┼──────────┼──────────
> 103179564 │ 20829222 │ 20815126 │ 26214400 │ 24426295
>
> Open points:
> * should these numbers be converted to bytes?
> * the column names currently mirror the statfs() names and should
> certainly be improved
> * which of these columns add to \db+ output?
> * possibly extend this (and \db) to pg_wal

Shouldn't we have something more generic, in hope that this eventually
get implemented on Windows? I'm also wondering if getting the fs
information is enough, as there might be quota.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Christoph Berg 2019-11-08 13:35:31 Re: Monitoring disk space from within the server
Previous Message Konstantin Knizhnik 2019-11-08 13:31:07 Re: Why overhead of SPI is so large?