On Tue, Nov 12, 2019 at 2:48 AM Michael Paquier wrote:
>
> On Mon, Nov 11, 2019 at 09:11:35PM +0100, Laurenz Albe wrote:
> > Will this work on Windows?
> > A quick web search seems to indicate that Windows has no statfs(2).
>
> It won't. We are actually discussing the compatibility aspects and
>
Re: Daniel Gustafsson 2019-11-12 <7a3b9bb6-bea0-466e-98a9-b4dd8f048...@yesql.se>
> I agree with Tomas upthread that it's unclear whether this needs to be in
> core.
> There are many system parameters a database admin is likely to be interested
> in, diskspace being just one of them (albeit a very
On Tue, Nov 12, 2019 at 09:47:47AM +0100, Daniel Gustafsson wrote:
> I agree with Tomas upthread that it's unclear whether this needs to be in
> core.
> There are many system parameters a database admin is likely to be interested
> in, diskspace being just one of them (albeit a very important one
> On 12 Nov 2019, at 02:46, Michael Paquier wrote:
> Any opinions?
I agree with Tomas upthread that it's unclear whether this needs to be in core.
There are many system parameters a database admin is likely to be interested
in, diskspace being just one of them (albeit a very important one for ma
On Mon, Nov 11, 2019 at 09:11:35PM +0100, Laurenz Albe wrote:
> Will this work on Windows?
> A quick web search seems to indicate that Windows has no statfs(2).
It won't. We are actually discussing the compatibility aspects and
the minimal data set we could grab in a different part of the thread.
On Sat, Nov 09, 2019 at 02:33:49PM +0100, Christoph Moench-Tegeder wrote:
> "The statfs() system call first appeared in 4.4BSD." (from the statfs(2)
> manpage on FreeBSD). struct statfs differs between Linux and BSD, but
> is "close enough" for this, the fields from the original patch are
> present
On Fri, 2019-11-08 at 14:24 +0100, Christoph Berg 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 repo
## Michael Paquier (mich...@paquier.xyz):
> Total bytes and free bytes looks like a good first cut. Have you
> looked at the portability of statfs() on other BSD flavors and
> Solaris?
"The statfs() system call first appeared in 4.4BSD." (from the statfs(2)
manpage on FreeBSD). struct statfs dif
On Fri, Nov 08, 2019 at 03:10:57PM +0100, Julien Rouhaud wrote:
> Agreed, inodes are probably not very useful there.
Total bytes and free bytes looks like a good first cut. Have you
looked at the portability of statfs() on other BSD flavors and
Solaris? I recall from a lookup at statvfs() that t
On Fri, Nov 08, 2019 at 04:06:21PM +0100, Christoph Berg wrote:
Re: Tomas Vondra 2019-11-08 <20191108145025.d7pfcip6plufxiah@development>
While I agree monitoring disk space is important, I think pretty much
every deployment already does that using some other monitoring tool
(which also monitors
Re: To Tomas Vondra 2019-11-08 <20191108150621.gl8...@msg.df7cb.de>
> I think this should be directly in core because it's useful to a wide
> range of users.
Also, I want to have it in \db+ in psql where users would actually be
looking for it.
Christoph
Re: Tomas Vondra 2019-11-08 <20191108145025.d7pfcip6plufxiah@development>
> While I agree monitoring disk space is important, I think pretty much
> every deployment already does that using some other monitoring tool
> (which also monitors million other things).
There are plenty of deployments wher
On Fri, Nov 08, 2019 at 02:24:19PM +0100, Christoph Berg 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.
While I agree monitoring disk space is important, I think pretty much
every de
On Fri, Nov 8, 2019 at 2:58 PM Christoph Berg wrote:
>
> Re: Julien Rouhaud 2019-11-08
>
> > 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
Re: Julien Rouhaud 2019-11-08
> > We could append the quotactl(Q_GETQUOTA) information as well, but I'm
> > not sure this has a sensible actual-users-to-noise ratio.
>
> Well, having a quota is one of the few real reason to create a
> tablespace so it's probably worth it, although I have to agr
Re: Julien Rouhaud 2019-11-08
> 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-fi
On Fri, Nov 8, 2019 at 2:40 PM Christoph Berg wrote:
>
> Re: Julien Rouhaud 2019-11-08
>
> > I'm also wondering if getting the fs
> > information is enough, as there might be quota.
>
> We could append the quotactl(Q_GETQUOTA) information as well, but I'm
> not sure this has a sensible actual-us
On Fri, Nov 8, 2019 at 2:35 PM Christoph Berg wrote:
>
> Re: Julien Rouhaud 2019-11-08
>
> > 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.
>
> The na
Re: Julien Rouhaud 2019-11-08
> I'm also wondering if getting the fs
> information is enough, as there might be quota.
We could append the quotactl(Q_GETQUOTA) information as well, but I'm
not sure this has a sensible actual-users-to-noise ratio.
Christoph
Re: Julien Rouhaud 2019-11-08
> 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.
The name is certainly not a good pick, it's not meant to be a raw
statfs()
On Fri, Nov 8, 2019 at 2:24 PM Christoph Berg 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
21 matches
Mail list logo