>>> On Thu, Feb 23, 2006 at 8:43 pm, in message <[EMAIL PROTECTED]>, Neil Conway <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster