>>> On Thu, Feb 23, 2006 at 8:43 pm, in message
<43FE72DB.8070701@samurai.com>,
Neil Conway <neilc@samurai.com> wrote:
> Kevin Grittner wrote:
>> Peter Brant, a consultant working with us, has written code which
is
>> working for this under both Linux and Windows. [...] For Linux, he
>> used statvfs.
>
> statvfs(2) is standardized, but doesn't seem portable: it isn't
> available on OSX 10.3, NetBSD 2.0 or OpenBSD, for example. Perhaps
you
> can fallback to statfs(2) when it is available?
>
> This seems an area where providing consistent cross- platform
behavior
> might be difficult. Do we actually need this functionality inside the
> DBMS in the first place?
It sounds like we should probably just shelve the idea of sharing this
code. It is very useful to us, since it allows a single database
connection to monitor the health of the database and detect impending
failure. Having our monitoring software need to know the operating
system of each database, with security to log into the OS of each
machine, would be far worse from a security standpoint, more fragile,
and more work than adding these functions to the database. But no
response so far has indicated any interest in it from any other quarter,
and it sounds like the portability issues are more than we want to deal
with here.
In response to a few other posts -- it is implemented with three
functions, which I was bundling to target the contrib level of
submission. One function returns a list of volumes (i.e., drive letters
in Windows, mount points in Linux), one returns available space for a
given volume, and one returns total space for a given volume.
Since we have what we need to get our work done, and the community at
large doesn't seem interested, I'll shelve the idea of submitting
anything.
Thanks for the responses.
-Kevin
