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 1v6ZMv-006ccx-JW for pgsql-general@arkaria.postgresql.org; Wed, 08 Oct 2025 18:58:34 +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 1v6ZMs-00CMv2-VD for pgsql-general@arkaria.postgresql.org; Wed, 08 Oct 2025 18:58:31 +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 1v6ZMs-00CMuo-Ih for pgsql-general@lists.postgresql.org; Wed, 08 Oct 2025 18:58:31 +0000 Received: from mail-pf1-x432.google.com ([2607:f8b0:4864:20::432]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1v6ZMp-0015TG-0h for pgsql-general@lists.postgresql.org; Wed, 08 Oct 2025 18:58:29 +0000 Received: by mail-pf1-x432.google.com with SMTP id d2e1a72fcca58-791c287c10dso141004b3a.1 for ; Wed, 08 Oct 2025 11:58:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1759949905; x=1760554705; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Y+0FjU8ZfWwoneBvqodrU0IQWBMYzew1GlkI3k1rsBM=; b=EJvbgThIC0dhykQWj2UjtnBF53kXPZOFa7k0C4GMEjP3+FHtmFwkDmdQ/zpkdBgtYT Msizjt8k5y1O/CLAhRD7Q2baUqbn7SmvQzkVrhDnGoNpkqZYTxeIXYeF/W4jXm2xdYUW kpghtOCNM9RP8NbwNbR6s/NB21ofrGbVRhrndMhPzh5RMCwighC3gq+w18Hm7lwDveie WAUApCXusRTFovSw+70Prml7Ao8/feTJMUR4aYzQZJuvyC6JvERsv4jEOJ47S6cY2m0C gN48DZVUx0NpRwlCO6flPKAzqps/SB0lAV085MwzMGbERlz1S7R7EblPi3PlmcQbZeqp ODSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1759949905; x=1760554705; h=cc: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=Y+0FjU8ZfWwoneBvqodrU0IQWBMYzew1GlkI3k1rsBM=; b=tXIz6HHTkItSzoFG7Re8wtK5YKU840LLJunV3vaTafIHnQJtMtLYjPjmLZ8Yi+4D2u 5ap8CegXKqpGEVY/M7sXllWZ11X9TkrRUoG+e3z7MUvi/WLzcKjWkwMhEQyD4dLKcX2K seAobC3/+OtHskNvRD1sCJFjlviwEFyxxyNJH4yt2eLaUbhyHL8DQRc960foLBNig2zv +zble6Mbyb152fz8Fozm3NhQluQ8ONNLsl81aW27gWYCWXa2Rhaf22atFIkrxLAqHbKT FJRhzBb9c9lv6w9ffdIOybLvZCC8bXk/hv6MmSR99ndal+sfz5Pu2FiFpFqfkWSjLlbT zpFA== X-Gm-Message-State: AOJu0YxFhqzpnoBPH8kSdG2IaAip1/6hqFFgFhxj7ubWVj6unc1oAsgX wHIJcBFUo88pqdC1QcYxzKwZGxErYPI8EOVLUMyMyir/2CI6GSlU0qYCXkZYQ9Vn+VtJob95mRQ sdWF5gUZaOQh0baIEFzfXlMzfsbK1INk= X-Gm-Gg: ASbGnctio7XSmmK7Oaf2S3XuS8wbLZ8m8+7AZeFhou6cMl1RfynnA0YBshgMjySAPhI 4fU87K4l/b9IxwRe928jdltsS4ONxI9Y6babCo8CligiUrnvVbnRGnbcNyyRoH9cm4nTqupQpSg EXM2J9H76RSxaEGeqxXYJLn0blFpcbHOA4VxShSppJ1c0GhzCfZR+uv7x7/py73LJj3mQnw5s2x jKqAXrhHajVXlqfma8ts+8cvPQcb7Ur9QON0RL0ONZOD3k+Ko+jLtEx5xsol/5ORQoBNFmI X-Google-Smtp-Source: AGHT+IG594QtrBQmVc2RMMcmSpzT9S+TCMBtelcsiURqi6yL83K8bGYhJ929AJw/ccGFxUPXPA4S1aw+ZCpb2q7DbAU= X-Received: by 2002:a17:902:cec2:b0:256:2b13:5f11 with SMTP id d9443c01a7336-290272e19bbmr65944475ad.40.1759949904688; Wed, 08 Oct 2025 11:58:24 -0700 (PDT) MIME-Version: 1.0 References: <9f175444-6bfc-4c6e-a609-e552d85c45a1@aklaver.com> In-Reply-To: <9f175444-6bfc-4c6e-a609-e552d85c45a1@aklaver.com> From: sud Date: Thu, 9 Oct 2025 00:28:11 +0530 X-Gm-Features: AS18NWDeVuralCeiNV8Oi-SiJkDLP0Gi1_DpJSlj6N0Tex05UTUtHQqNP_CkyQo Message-ID: Subject: Re: Alerting on memory use and instance crash To: Adrian Klaver , Ron Johnson Cc: pgsql-general Content-Type: multipart/alternative; boundary="000000000000e43a7b0640aa4473" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000e43a7b0640aa4473 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you. My understanding may be wrong here.And my apology as I am using the example of Oracle again even though these two are not the same. But being worked for a long time in Oracle so trying to understand exactly how it's different. In oracle RAC(real application cluster) database, we have single databases with multiple nodes/instances/memory, which means the underlying storage is same but the memory/cpu of each of those instances are different and any of the instances can be down but the database still operates routing the application traffic of the downed node to others. Similarly even in AWS Aurora postgres also there can be multiple instances like Writer and Reader instances/nodes and the underlying storage being the same. So I was thinking of any such cluster level pg_* views available by querying which we would be able to know if any one of the nodes is down ? Also , I don't see any such pg_* view which can show the statistics of all the instances combinely i.e. cluster level statistics. Do you mean in normal Postgres it's alway a single instance/memory and single storage attached? then I also do not see any such cluster level views in aws aurora postgres too? Pardon if it's a silly one to ask. On Wed, Oct 8, 2025 at 9:52=E2=80=AFPM Adrian Klaver wrote: > On 10/8/25 08:42, 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 :- > > In other databases like Oracle the catalog Views like "GV$Instance" use= d > > to give information on whether the instances are currently active/down > > or not. But in postgres it seems all the pg_* views are instance > > specific and are not showing information on the global/cluster level bu= t > > 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? > > 1) When you say instance do you mean database? > > 2) Not all system tables/views are database only. > > For instance: > https://www.postgresql.org/docs/current/catalog-pg-database.html > https://www.postgresql.org/docs/current/catalog-pg-auth-members.html > https://www.postgresql.org/docs/current/catalog-pg-authid.html > https://www.postgresql.org/docs/current/view-pg-roles.html > > > > 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= ? > > > > Appreciate your guidance. > > > > Regards > > Sud > > > -- > Adrian Klaver > adrian.klaver@aklaver.com > --000000000000e43a7b0640aa4473 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you.
My understanding may be wrong here.An= d my apology as I am using the example of Oracle again even though these=C2= =A0two are not the same. But being worked for a long time in Oracle so tryi= ng to understand exactly how it's different.

In orac= le RAC(real application cluster) database, we have single databases with mu= ltiple nodes/instances/memory, which means the underlying storage is same b= ut the memory/cpu of each of those instances are different and any of the i= nstances can be=C2=A0down but the database still operates routing the appli= cation traffic of the downed node to others. Similarly even in AWS Aurora p= ostgres also there can be multiple instances like Writer and Reader instanc= es/nodes and the underlying storage being the same. So I was thinking of an= y=C2=A0such cluster level pg_* views available=C2=A0by querying which we wo= uld be able to know if any one of the nodes is down ?=C2=A0 =C2=A0Also , I = don't see any such pg_* view which can show the statistics of all the i= nstances combinely i.e. cluster level statistics.=C2=A0

Do you mean in normal Postgres it's alway a single instance/memor= y and single storage attached? then I also do not see any such cluster leve= l views in aws aurora postgres too? Pardon if it's a silly one to ask.= =C2=A0



On Wed, Oct= 8, 2025 at 9:52=E2=80=AFPM Adrian Klaver <adrian.klaver@aklaver.com> wrote:
On 10/8/25 08:42, sud wrote:
> Hi Experts,
>
> It's postgres version 16. I have two questions on alerting as belo= w.
>
> 1)If we want to have alerting on any node/instance that gets crashed := -
> In other databases like Oracle the catalog Views like "GV$Instanc= e" 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
> specific and are not showing information on the global/cluster level b= ut
> are restricted to instance level only. So is there any other way to > query the pg_* views to have=C2=A0alerts on the specific instance cras= h?

1) When you say instance do you mean database?

2) Not all system tables/views are database only.

For instance:
https://www.postgresql.org/docs/curr= ent/catalog-pg-database.html
https://www.postgresql.org/docs/= current/catalog-pg-auth-members.html
https://www.postgresql.org/docs/curren= t/catalog-pg-authid.html
https://www.postgresql.org/docs/current/v= iew-pg-roles.html


> 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 postgre= s?
>
> Appreciate your guidance.
>
> Regards
> Sud


--
Adrian Klaver
adrian.klave= r@aklaver.com
--000000000000e43a7b0640aa4473--