Re: Monitoring disk space from within the server
От | Julien Rouhaud |
---|---|
Тема | Re: Monitoring disk space from within the server |
Дата | |
Msg-id | CAOBaU_aENmaDNO7Y=iG=L2Wsjwje4HPxt5+c623_OfCwSzDKmQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Monitoring disk space from within the server (Christoph Berg <myon@debian.org>) |
Ответы |
Re: Monitoring disk space from within the server
|
Список | pgsql-hackers |
On Fri, Nov 8, 2019 at 2:58 PM Christoph Berg <myon@debian.org> wrote: > > Re: Julien Rouhaud 2019-11-08 <CAOBaU_Zu6RP6-mHyA_J9-xkxJe0tarTVqU9TFza+tCPKUxsjiA@mail.gmail.com> > > The related function on Windows is apparently GetDiskFreeSpaceA [1]. > > There's a link to GetDiskFreeSpaceExA() which seems much easier to use > because it accepts any directory on the drive in question: > > https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getdiskfreespaceexa > > > It'll probably be quite hard to get something consistent for most of > > counters, so probably pg_tablespace_(disk_)space is the best name, > > providing only total size and free size? > > So, how about: > > pg_tablespace_disk_space -> total_bytes | free_bytes > > The inode numbers are probably not very interesting in a PG tablespace > as we don't create that many files. Or do we think including these > counters (on UNIX) makes sense? Agreed, inodes are probably not very useful there. > There's precedents for leaving fields NULL where not supported by the > OS, for example pg_stat_file() returns "change" on UNIX only, and > "creation" on Windows only. > [...] > Given that PG deals badly with one tablespace being full (might work > in production, but if it's full during recovery, the whole server will > stop), I've never seen quotas being used. I'm +1 on "pg_tablespace_disk_space -> total_bytes | free_bytes"
В списке pgsql-hackers по дате отправления: