Re: Available disk space per tablespace - Mailing list pgsql-hackers

On Sat, Mar 15, 2025 at 4:40 AM Christoph Berg <myon@debian.org> wrote:
> I'm still unconvinced if we should use statfs() instead of statvfs()
> on *BSD or if their manpage is just trolling us and statvfs is just
> fine.
>
> DESCRIPTION
>        The statvfs() and fstatvfs() functions fill the structure pointed to by
>        buf  with  garbage.  This garbage will occasionally bear resemblance to
>        file system statistics, but portable applications must  not  depend  on
>        this.

Hah, I see this in my local FreeBSD man page.  I guess this might be a
reference to POSIX's 100% get-out clause "it is unspecified whether
all members of the statvfs structure have meaningful values on all
file systems".  The statfs() man page doesn't say that (a nonstandard
syscall that originated in 4.4BSD, which POSIX decided to rename
because other systems sprouted incompatible statfs() interfaces?).
It's hard to imagine a system that doesn't track free space and report
it here, and if it doesn't, well so what, that's probably also a
system that can't report free space to the "df" command, so what are
we supposed to do?  We could perhaps add a note to the documentation
that this field relies on the OS providing meaningful "avail" field in
statvfs(), but it's hard to imagine.  Maybe just defer that until
someone shows up with a real report?  So +1 from me, go for it, call
statvfs() and don't worry.

I tried your v3 patch on my FreeBSD 14.2 battle station:

postgres=# \db+
                                     List of tablespaces
    Name    | Owner  | Location | Access privileges | Options |  Size
|  Free  | Description
------------+--------+----------+-------------------+---------+--------+--------+-------------
 pg_default | tmunro |          |                   |         | 22 MB
| 290 GB |
 pg_global  | tmunro |          |                   |         | 556 kB
| 290 GB |

That is the correct answer:

tmunro@build1:~/projects/postgresql/build $ df -h .
Filesystem        Size    Used   Avail Capacity  Mounted on
zroot/usr/home    331G     41G    290G    12%    /usr/home

I also pushed your patch to CI and triggered the NetBSD and OpenBSD
tasks and they passed your sanity test, though that only checks that
the reported some number >  1MB.

I looked at the source, and on FreeBSD statvfs[1] is just a libc
function that calls statfs() (as does df).  The statfs() man page has
no funny disclaimers.  OpenBSD's[2] too.  NetBSD seems to have a real
statvfs (or statvfs1) syscall but its man page has no funny
disclaimers.

+#ifdef WIN32
+       if (GetDiskFreeSpaceEx(tblspcPath, &lpFreeBytesAvailable,
NULL, NULL) == false)
+               return -1;
+
+       return lpFreeBytesAvailable.QuadPart; /* ULONGLONG part of
ULARGE_INTEGER */
+#else
+       if (statvfs(tblspcPath, &fst) < 0)
+               return -1;
+
+       return fst.f_bavail * fst.f_frsize; /* available blocks times
fragment size */
+#endif

What's the rationale for not raising an error if the system call
fails?  If someone complains that it's showing -1, doesn't that mean
we'll have to ask them to trace the system calls to figure out why, or
if it's Windows, likely abandon all hope of ever knowing why?  Should
statvfs() retry on EINTR?

Style nit: maybe ! instead of == false?

Nice feature.

[1] https://github.com/freebsd/freebsd-src/blob/36782aaba4f1a7d054aa405357a8fa2bc0f94eb0/lib/libc/gen/statvfs.c#L70
[2] https://github.com/openbsd/src/blob/70ab9842eb8b368612eb098db19dcf94c19d673d/lib/libc/gen/statvfs.c#L59