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 1v6Wva-005ztq-Ru for pgsql-general@arkaria.postgresql.org; Wed, 08 Oct 2025 16:22:11 +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 1v6WvY-00BL5E-Ja for pgsql-general@arkaria.postgresql.org; Wed, 08 Oct 2025 16:22:09 +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 1v6WvY-00BL56-97 for pgsql-general@lists.postgresql.org; Wed, 08 Oct 2025 16:22:09 +0000 Received: from mail-ot1-x333.google.com ([2607:f8b0:4864:20::333]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1v6WvX-00145F-0A for pgsql-general@lists.postgresql.org; Wed, 08 Oct 2025 16:22:08 +0000 Received: by mail-ot1-x333.google.com with SMTP id 46e09a7af769-7bc626c5467so28754a34.2 for ; Wed, 08 Oct 2025 09:22:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1759940525; x=1760545325; darn=lists.postgresql.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=5JnYIil/NxZQxKtqSj+ouigzx/rAx+62NUYONMpbTuY=; b=cbWj8vMtKuMA2bnsTtDx7r7bN6fVvQJXSSJISEEYc+1kCIGW4ow40UA1k3UjiqQAC4 w+aWH3P9onOe3MYL9KHd2ZNygt4Mj4vB1Vi6R3rdfVWtzemMpu3nEugXN0ny3I4So2vo hcU2lnWhaAslXUwT1CQcvgM+QPqGdm4G5tJKtIqAhi7yNHckRURIkPdyoUZprtuNyYWF CNwB5snmGpdJGNMYu9nuapK2v4NVH5huHXuy3rcZ7M9V3nBNAXI62fn9xfW+3QGugrh/ x6q2y62vGX3jdcezz/XdQetqCIhLeyEYLS3Wu3Mpo3bkaDscmamC4xisvK91iGbF/kBi k5zQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1759940525; x=1760545325; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=5JnYIil/NxZQxKtqSj+ouigzx/rAx+62NUYONMpbTuY=; b=INNLDJagTNmSAq05ANYQCSyFoJVrm/uskwGz2z1rMD+MEUn237FNJ26QJsvjyP52XL HZUIvdUM9/rFMEz5NkakNddY4B4t7tB2rd1FlbR4ULnWB37b0DIhyLHFtcJb/oQ1tLHv 3+YTrvK6tvGKuLH/A4MwKaurM8PFZja3moLgKHuYOdygGk+lr7/4JufL9gi3/CU6H4wp Go43B3Y1q1yltsKYT1E81EgDyQYo2eWgdZB8D69U1fqKikqMgCatkmeZXkSWdODR8Hv/ V1/WWIPOEOAv9VjCJgEukrCV8bEdLZMwZ7rM0XxqkZkNM8eNgCRZBcgOu4ILuPfANLUG DH6g== X-Gm-Message-State: AOJu0YwAlqEDfFVixwkEZg9Ugq+DodpXI7F/LxqQxMZHQh5CXZF9z24V qc4WrgcSegpkL3CLokcoYXhx7pxyKo9Lu+Mli2m/f59EVL3wAsSAgs3z5cmAUbUXudIMO5zpmuZ swo3aNL2ye1PJLth2r4w9f5JRn3ozBdMNsLhR X-Gm-Gg: ASbGncsbhpXbrsYdkKQeyNtj5TQc6Pn2sbsbQNNnfTGxWoqVDI6K5DIPGwQ/0MVzua9 fI4ASSW4Hj07+00aGzbugz2tw0ZkjhQdJGkGqUdk2+zzmN1kpQakAwgvuLehS+85rE8tKav2zGm rttD+r47HDNTNxQovAEZZF3B0Aq6Sbq/cDzOTv0maxhn6bODp1WV39RvlH/T52gorzYhRfwYMsM bGo4TwBcLlnwyhnwNNFkT2Z0JjG2hEJxlnPHYqyHZo= X-Google-Smtp-Source: AGHT+IFhwNEseCYmWASCb4KuI+fXkuwTbktJcZ8ngKIjiRZWLdCzWd7Wp3deFxEg3fPQdSp/nS70jiHUdStp3JzckfQ= X-Received: by 2002:a05:6871:287:b0:31d:6d47:c648 with SMTP id 586e51a60fabf-3c0f9e65891mr2430097fac.47.1759940524627; Wed, 08 Oct 2025 09:22:04 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ron Johnson Date: Wed, 8 Oct 2025 12:21:53 -0400 X-Gm-Features: AS18NWAmTjXApXX-zwx_3ojXxHyjBYbWELLkMUkEez7dm5kkny5K4UzWs9OOY5I Message-ID: Subject: Re: Alerting on memory use and instance crash To: pgsql-general Content-Type: multipart/alternative; boundary="000000000000cbe0420640a81536" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000cbe0420640a81536 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Oct 8, 2025 at 11:42=E2=80=AFAM sud wrote: > Hi Experts, > > It's postgres version 16. I have two questions on alerting as below. > > 1)If we want to have alerting on any node/instance that gets crashed :- I= n > other databases like Oracle the catalog Views like "GV$Instance" used to > give information on whether the instances are currently active/down or no= t. > But in postgres it seems all the pg_* views are instance specific and are > not showing information on the global/cluster level but are restricted to > instance level only. So is there any other way to query the pg_* views to > have alerts on the specific instance crash? > In Postgresql, cluster =3D=3D instance. That's a historical fluke which mi= ght never go away. Thus, if the cluster is down, you can't access anything. Connection poolers that use virtual IP addresses and are the modern definition of "cluster" sit on top of individual PG clusters. Even though the pooler auto-fails the (modern) cluster to the replica instance, PG still thinks one cluster is down, and the former-replica cluster is now the primary cluster. Confusing? Yes. Just accept that *PG cluster =3D=3D instance*, and that *Postgresql is not Oracle*. > 2)Is there a way to fetch the data from pg_* view to highlight the > specific connection/session/sqls which is using high memory in postgres? > --=20 Death to , and butter sauce. Don't boil me, I'm still alive. lobster! --000000000000cbe0420640a81536 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Oct 8, 2025 at 11:42=E2=80=AFAM s= ud <suds1434@gmail.com> wro= te:
Hi Experts,

It'= ;s postgres version 16. I have two questions on alerting as below.

<= div>1)If we want to have alerting on any node/instance that gets crashed :-= In other databases like Oracle the catalog Views like "GV$Instance&qu= ot; used to give information on whether the instances are currently active/= down or not. But in postgres it seems all the pg_* views are instance speci= fic and are not showing information on the global/cluster level but are res= tricted to instance level only. So is there any other way to query the pg_*= views to have=C2=A0alerts on the specific instance crash?
<= /blockquote>

In Postgresql, cluster =3D=3D instance.=C2= =A0 That's a historical fluke which might never go away.=C2=A0 Thus, if= the cluster is down, you can't access anything.

Connection poolers that use virtual IP addresses and are the modern defi= nition of "cluster" sit on top of individual PG clusters.=C2=A0 E= ven though the pooler auto-fails the (modern) cluster to the replica instan= ce, PG still thinks one cluster is down, and the former-replica cluster is = now the primary cluster.

Confusing?=C2=A0 Yes.=C2= =A0 Just accept that PG cluster =3D=3D instance, and that Postgre= sql is not Oracle.
=C2=A0
2)Is there a way to fetch the dat= a from pg_* view to highlight the specific connection/session/sqls which is= using high memory in postgres?



--
Death to <Redacted>, and butter sauce.
Don't boil me, I= 'm still alive.
<Redacted> lobster!
--000000000000cbe0420640a81536--