Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iUG2H-0003YR-Mt for pgsql-hackers@arkaria.postgresql.org; Mon, 11 Nov 2019 20:11:41 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1iUG2F-0008EU-VP for pgsql-hackers@arkaria.postgresql.org; Mon, 11 Nov 2019 20:11:39 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iUG2F-0008EM-Mo for pgsql-hackers@lists.postgresql.org; Mon, 11 Nov 2019 20:11:39 +0000 Received: from mail-wr1-x442.google.com ([2a00:1450:4864:20::442]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iUG2D-0000V8-BE for pgsql-hackers@postgresql.org; Mon, 11 Nov 2019 20:11:38 +0000 Received: by mail-wr1-x442.google.com with SMTP id t1so16068686wrv.4 for ; Mon, 11 Nov 2019 12:11:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybertec-at.20150623.gappssmtp.com; s=20150623; h=message-id:subject:from:to:date:in-reply-to:references:user-agent :mime-version:content-transfer-encoding; bh=V/gDYHPXVZospiJGYT7l9v6CHtLt4Xm4+KcylFLRN6o=; b=BEbAUcpW5Z4ZZCkUpwg5MRX1hPFP5Ytjdj6t9ZaU9VRPP5Bx6ufO66pkt81u/SQyDM qGwM/HV0ZsZfQ+zCE3LY8Zj4d/fa+eE4ab2oUl0ceMETFb14e9hOrAcVc84olCopDAdf PSj8RlBOWygzKY5Mhz4GxQVwyJF1ajMeLShrKFvBZJhPWlW99yobPGmtnejKhTAwolfV jI5n7P3RWOrlApLWanCi8FDjFufeeH2c1B66CQN4R8BQP2Lf1ymeoP487VafT52oOrGm c+oB7FsLwxHc2JNVyPSa7V0jukUTWPLrRJbm+kTdhZZ2wzbDaJa7T9yyeQ9oXI4MNIZH B0Xw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=V/gDYHPXVZospiJGYT7l9v6CHtLt4Xm4+KcylFLRN6o=; b=rM+zwSy8HqWpbeCFgjUSrmZitKS6HsAXYqcKlya+okN0Tm8ne0GT/p+bXPvXRQoYvS VTapExAOMnda2hfNthPq2QzBOtriyBYu6IYC0vq0OGz/MLRAj+kR1T0CptIpmMSSymqg r8R7KFqnWGJOMUQzWx4W0bXpB5SQLL34chNzrqgXZaAsNcPywyOodjmwA/SKjjkiD6YZ PJXCZgxtFE9PVo59wUCO77OXoobvBFP0grFcO8nKsgGwLT4tFVZoT6+bP3+T49K4E+xA Ijvdwryse08/QbErzzDDSqYTifFtalpRlWO6mFscqLe3tKzYUVpEDnDjFzGcOXQlwvfF zv4g== X-Gm-Message-State: APjAAAXubKPYGr9PqWV4jLxBoirEDs4NjGvh2fXmnFFBuxpodq3gjrXj MfuVj+q7e+F/bRfeNQiJU9NLINp2KW2eqw== X-Google-Smtp-Source: APXvYqyJdxqcAR3Lhkmr39iiVJIB4QFDltAdGj4gpxKQB0/iPRLbIBPPUb2tQMd2+f1/F1LL+n1WmA== X-Received: by 2002:a5d:55c7:: with SMTP id i7mr4438787wrw.64.1573503096256; Mon, 11 Nov 2019 12:11:36 -0800 (PST) Received: from localhost.localdomain (217-149-174-164.nat.highway.telekom.at. [217.149.174.164]) by smtp.gmail.com with ESMTPSA id n1sm19552631wrr.24.2019.11.11.12.11.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 Nov 2019 12:11:35 -0800 (PST) Message-ID: <9d7165a201fe3ce3a00755b4474bb618b3ddba5e.camel@cybertec.at> Subject: Re: Monitoring disk space from within the server From: Laurenz Albe To: Christoph Berg , PostgreSQL Hackers Date: Mon, 11 Nov 2019 21:11:35 +0100 In-Reply-To: <20191108132419.GG8017@msg.df7cb.de> References: <20191108132419.GG8017@msg.df7cb.de> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.32.4 (3.32.4-1.fc30) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk 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 report disk space numbers per tablespace: > > # select * from pg_tablespace_statfs('pg_default'); > blocks │ bfree │ bavail │ files │ ffree > ───────────┼──────────┼──────────┼──────────┼────────── > 103179564 │ 20829222 │ 20815126 │ 26214400 │ 24426295 > > Open points: > * should these numbers be converted to bytes? > * the column names currently mirror the statfs() names and should > certainly be improved > * which of these columns add to \db+ output? > * possibly extend this (and \db) to pg_wal Will this work on Windows? A quick web search seems to indicate that Windows has no statfs(2). What's more is that the Linux man page says that statfs(2) is Linux-specific. I think that if we have such a feature (which I think would be useful) should be available for all operating systems supported by PostgreSQL. Yours, Laurenz Albe