Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1v25cr-000CRR-2F for pgsql-general@arkaria.postgresql.org; Fri, 26 Sep 2025 10:24:29 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1v25bq-000LNJ-PS for pgsql-general@arkaria.postgresql.org; Fri, 26 Sep 2025 10:23:27 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1v25bq-000LN7-CQ for pgsql-general@lists.postgresql.org; Fri, 26 Sep 2025 10:23:27 +0000 Received: from mail-ej1-x633.google.com ([2a00:1450:4864:20::633]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1v25bp-000CRF-0B for pgsql-general@lists.postgresql.org; Fri, 26 Sep 2025 10:23:26 +0000 Received: by mail-ej1-x633.google.com with SMTP id a640c23a62f3a-b2e168f0a75so347783366b.0 for ; Fri, 26 Sep 2025 03:23:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1758882204; x=1759487004; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=ybD3KZvxUAP89P5bl6ua/jAeuK3QNbHWjcYLsIXsPCU=; b=k/jEUgC6Nug67ex65gkfBMU66Mb/T8RLyeAcfMlbIB+qF57a/H3HAfDTLwm63Z3Gqa c8BogNW3I7Zxn+wdEWwF9O15YdhzCNPdUMp/XotTW6TuY4feEluRU+1MN0MOzzryhR6J tM8/HixpcDY9RzZPQuWFTLE1VzrJAh+Lgm4kBxxCzXgKWBkItf9wBsSO8x6ZcUeImbnK kAjtwAblWOxHBYPo/PA08MjPxRZJgm4F2Zg+hUK8aw/O6TzXmqfcGZO6gHwlDkE+Zqg0 PvjwLsJMdoHx/2BXIS6x7tWrgCANYn607714EmE9xYI2I64ySVQErAUsXJg7spVol1d2 0stQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1758882204; x=1759487004; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=ybD3KZvxUAP89P5bl6ua/jAeuK3QNbHWjcYLsIXsPCU=; b=c+ltHHi5u97ko7HHJI8CKZpzTsIzz9MbZSZfIhE1XsEKC5NR7+NTLlXATr+VP7vDmD TtR0EzKpy9aUSQVAz35gaiDkWYD72nVKlevwocL+WhdUnpmfXo5Nos+Wn8zxcMNLoJxM tZ+lUGx5ai//3G5WhuPpIgTidMYXrQPFEXl6Seb5bO5SQZ6dFnlN+jNkeGnreC1HCNq1 zUAkxx8vZkoR9BQzIk6Az3/1YYXgeFxRZ7TAR4ttLhk+3zi5Lf8+3XRzLPO5MIr4dYww xIYMguN/F8tYpkfwL0tYUdyJMM0psLDxqTYOXuWleH+UHaT/CvB2ZzMnTWLYfyDW0ZMe e7Iw== X-Gm-Message-State: AOJu0YyXJGKUeTLzzEkDZsM2P0lBr5M9Y1qcvpG44eScSsKOUofrxscE UiiGm+vi1bc8ScknIkpZXdVt6EEvx50fVcttJ32JH/skleUTUQcwqZue6Cu9VLApEx6jdLFYJho TvB2dTHhgF7P72GCZGcq2tOBYLXeYlsB0Btqd X-Gm-Gg: ASbGnctxURda9NlqJg8P8WiTMQVQLj/Bm9W07syGeOYpB8jzpTa/1SkbdOpsMSlJ4SD Y5yvXBkJ/3mIl9DGRrduJ/mhQILYbSfvggMJVK49On/g0pTlX3Ragj9O7AUzH1bp5R1iX+l8Br7 suUb5cwzfS3L7D+VDz59Gm/5g65T7/k/z/GQpE6ChlUoVUyrlZ9HsIPGQlOtBXDgjnZcHwZdVrX eLUrj1o4cQD75TLusuKSO9HLOR28JBjOwMcxjbS X-Google-Smtp-Source: AGHT+IHSbZZkPDSqbpRZ1shaRwB1EpMXsAJ7b988jlapxDCkcqu5zRMo7wJUiDpnq5LdtCCmnTOrA/yEddtlct6C3aw= X-Received: by 2002:a17:907:7282:b0:b2f:75f7:67e7 with SMTP id a640c23a62f3a-b34ba639a4fmr712651266b.31.1758882203725; Fri, 26 Sep 2025 03:23:23 -0700 (PDT) MIME-Version: 1.0 From: veem v Date: Fri, 26 Sep 2025 15:53:13 +0530 X-Gm-Features: AS18NWC8xYezk2YBFZP6JbHjaZTHS2S-acsURUeAJk3NFY35PVyi4tjzOZnguuo Message-ID: Subject: Correct query for monitor To: pgsql-general Content-Type: multipart/alternative; boundary="000000000000f47516063fb1ac24" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000f47516063fb1ac24 Content-Type: text/plain; charset="UTF-8" Hello, We want to have monitoring on three things 1) If the database restarted or went down in the last few hours? 2)If the connections are high 3) High tablespace growth . Want to understand , if we can utilize below queries for the same or any flaws in this strategy? 1)SELECT CASE WHEN now() - pg_postmaster_start_time() < interval '12 hours' THEN 'ALERT: DB was restarted in the last 12 hours' ELSE 'OK' END AS status; 2)SELECT CASE WHEN conn_count > max_conn * 0.8 THEN 'ALERT: Connection usage is above 80%' ELSE 'OK: Connection usage is under control' END AS status, conn_count AS current_connections, max_conn AS max_connections, ROUND(conn_count * 100.0 / max_conn, 2) AS percent_used FROM ( SELECT COUNT(*) AS conn_count, (SELECT setting::int FROM pg_settings WHERE name = 'max_connections') AS max_conn FROM pg_stat_activity ) sub; 3)SELECT spcname, pg_size_pretty(pg_tablespace_size(oid)) AS size FROM pg_tablespace; Regards Veem --000000000000f47516063fb1ac24 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,
We want to have monitoring on three things 1) If= the database restarted or went down in the last few hours? 2)If the connec= tions are high 3) High tablespace growth . Want to understand , if we can u= tilize below queries for the same or any flaws in this strategy?

1)SELECT
=C2=A0 CASE
=C2=A0 =C2=A0 WHEN now()= - pg_postmaster_start_time() < interval '12 hours'
=C2=A0 = =C2=A0 THEN 'ALERT: DB was restarted in the last 12 hours'
=C2= =A0 =C2=A0 ELSE 'OK'
=C2=A0 END AS status;
=C2=A0
2)SELECT=
=C2=A0 =C2=A0 CASE
=C2=A0 =C2=A0 =C2=A0 =C2=A0 WHEN conn_count >= ; max_conn * 0.8 THEN
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 'AL= ERT: Connection usage is above 80%'
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ELSE=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 'OK: Connection usage is= under control'
=C2=A0 =C2=A0 END AS status,
=C2=A0 =C2=A0 conn_c= ount AS current_connections,
=C2=A0 =C2=A0 max_conn AS max_connections,<= br>=C2=A0 =C2=A0 ROUND(conn_count * 100.0 / max_conn, 2) AS percent_usedFROM (
=C2=A0 =C2=A0 SELECT
=C2=A0 =C2=A0 =C2=A0 =C2=A0 COUNT(*) AS= conn_count,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (SELECT setting::int FROM pg_se= ttings WHERE name =3D 'max_connections') AS max_conn
=C2=A0 =C2= =A0 FROM pg_stat_activity
) sub;

3)SELECT spcname, pg_size_pretty= (pg_tablespace_size(oid)) AS size
FROM pg_tablespace;

Regards
Veem
--000000000000f47516063fb1ac24--