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 1v7F2N-00HF9m-Aq for pgsql-general@arkaria.postgresql.org; Fri, 10 Oct 2025 15:28:07 +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 1v7F2L-00Cnoz-31 for pgsql-general@arkaria.postgresql.org; Fri, 10 Oct 2025 15:28:06 +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 1v7F2K-00Cnoq-NV for pgsql-general@lists.postgresql.org; Fri, 10 Oct 2025 15:28:05 +0000 Received: from mail-pl1-x62b.google.com ([2607:f8b0:4864:20::62b]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1v7F2J-001R8t-1H for pgsql-general@lists.postgresql.org; Fri, 10 Oct 2025 15:28:05 +0000 Received: by mail-pl1-x62b.google.com with SMTP id d9443c01a7336-2681660d604so26462985ad.0 for ; Fri, 10 Oct 2025 08:28:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1760110081; x=1760714881; 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=CRgOMkiC9WseKWSo3TzglCreeZ6IasWDYu2u021uN1U=; b=nECR6bAviAuN/cXQKWmjQPZcsgUhcRX2CQCHYcli5reK5+mWDy6ZdAmFljZj3qE7ZP ndb9HJMcxm8XK/G7b8EAdMNoeQs/MAkKxSjg5NMvUs/hrzEmXejMp7NpxjzQeW88MPjv VoiskduIIX+9KzQQxOnzZlXfXcvDgz1fS9dSrpiq7KzYKNKLpaa0UJrOGvHStANe7URB nAev+k6FUdibzTSVGOTvzUf5nRVDERAZavwlIsML96vR8QKnEH5rr+xW9nwrzszdUL3V FTJVnER5GqZQYeFziBX4C9/RwPx0TQ/qa4qT9sYPL+b0o2DN4oPzKrnGqNFzYbHdFzyV mQtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1760110081; x=1760714881; 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=CRgOMkiC9WseKWSo3TzglCreeZ6IasWDYu2u021uN1U=; b=kWVg7ArHjxAFRjbNNwDw5ORGRn+XJrv6MPjL8XIZmq90WOMvzKM4JPI2T4U2jICMXf D26y7qZbcbGNXIVHcwRxlKOZmS3uerrJF6NNOCRXeo/wQmTiy79k3vIL5hRGwVwqyq8p 4JbC0XsK1wBllArc8Agp76C67CvU/O2cKRtFd9/sADJoXGo2HON46IzEMiDi0Y9xbgmW 8M7rkErdb65ZUzx4N3yjA0zAf2ooRVy4QWA1NzD5k6cyCnWwqlueuHJnp2/aq7JvWjQ6 f382JUw/tBLDvAY6ubjfmTiX7Q5pBk7qlb7201keFTO8CVnV8dkd/IemgDpDb+0OKxE8 k5vw== X-Forwarded-Encrypted: i=1; AJvYcCVZsuY8I91KujGm1qGQvwcY/8dZtVYIei7qodMH9bttJhV6+SAnO++pGtumYqG3jYaoAzbiIYfVY/HOV6ny@lists.postgresql.org X-Gm-Message-State: AOJu0Yy7TJXPsGRlpK60gnHeLF+AAS6WoxrVVmPNDXpvsOO5L4xwoRbC rp9yr0Xav4Rlu4a4ciro5OU9E5a/n5xxFzzKRzTrt3li6X6f2Z9FoLNVA7f3zxWlx7vYs+m3N+l XhvmNa8GpT+TznPH9iqLRuHk5Rzhi1ok= X-Gm-Gg: ASbGncveI7ZwpBFIiQFoqfqLGQ6nJz4D5QzZTxHkg5welvZScqPdIpVTz3fcIlLarMI uJ1TLFRacnNxPKV9OXnWebDQLFcTB9X1iU0o9I0bp9hv3zxPCYljLAteTO+c77AGQ92b7z4ZaA5 CQst0eVBsm8dwnfc+3dSu/fgyJCWc5lisLhIxKYjgWdkrUpTe1OVB5i9ha8beMNE2bQXbkaVyCp yKo/2pXbSbD8ygy9pTKOHyU6j5yw5boQYIaYPO1iTN4HYbBuHf6HIVf0nKT8pSljz8= X-Google-Smtp-Source: AGHT+IGayCz90h9K75XmtXLg0ND2Ww0xwFOA1TjTEc26N0RO7G6OpbpbOtpTobW4sHigSEIiALr2eHMwgMA8tJCFWl8= X-Received: by 2002:a17:902:e883:b0:271:fead:9930 with SMTP id d9443c01a7336-290272f835amr184512845ad.59.1760110081301; Fri, 10 Oct 2025 08:28:01 -0700 (PDT) MIME-Version: 1.0 References: <9f175444-6bfc-4c6e-a609-e552d85c45a1@aklaver.com> In-Reply-To: From: sud Date: Fri, 10 Oct 2025 20:57:47 +0530 X-Gm-Features: AS18NWD_5ky1PyTN7155bGvVrdL6vF8cXLppJ2icw6MzSi4uz_Ie6EZ8pQiNoC4 Message-ID: Subject: Re: Alerting on memory use and instance crash To: Rahila Syed Cc: Ron Johnson , pgsql-general Content-Type: multipart/alternative; boundary="0000000000002960c50640cf90a5" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000002960c50640cf90a5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you so much. That helps. I am planning to use pg_stat_get_backend_memory_contexts function something as below by joining this to the pg_stat_activity. Hope this is the right usage. Somehow i am getting an error stating the function doesn't exist but it might be because of the version. I will try with a higher version. SELECT pa.pid, pa.usename, pa.application_name, pa.state, mc.name AS memory_context, pg_size_pretty(mc.used_bytes) AS used_memory FROM pg_stat_activity pa JOIN LATERAL pg_stat_get_backend_memory_contexts(pa.pid) mc ON TRUE WHERE pa.pid <> pg_backend_pid() ORDER BY mc.used_bytes DESC; However, is the below query, which was shared by Veem in above email thread is also going to give similar memory consumption information i.e. Avg memory consumption per query from pg_stat_statements? WITH block_size AS ( SELECT setting::int AS size FROM pg_settings WHERE name =3D 'block_size' ) SELECT query, calls, pg_size_pretty(temp_blks_read * bs.size) AS temp_read_in_bytes, pg_size_pretty(temp_blks_written * bs.size) AS temp_written_in_bytes FROM pg_stat_statements, block_size bs WHERE temp_blks_read > 0 OR temp_blks_written > 0 ORDER BY temp_blks_written DESC LIMIT 10; On Fri, Oct 10, 2025 at 4:08=E2=80=AFPM Rahila Syed wrote: > Hi, > > The other question I had was , are there any pg_* views using which, we >> are able to see which session/connection is using the highest amount of >> memory? I don't see any such columns in pg_stats_activity >> > > From a purely postgresql database point of view, this feature is being > developed, you can view it here : PostgreSQL: Enhancing Memory Context > Statistics Reporting > > > Basically, this lets you provide the pid of any PostgreSQL process to an > sql function, which then returns its memory usage statistics. > Once this feature is committed, for obtaining memory usage statistics of > any postgresql session you would need to run > SELECT pg_backend_pid() which will give you the pid of the postgresql > backend. > You can then pass it to SELECT pg_get_process_memory_contexts(pid, ..), > which will return the memory consumption data. > This is for future reference. > > At the moment, you can use the following function on the connection whose > memory you wish to inspect. > This works only for local connection i.e you can't use this function to > query the statistics of any other > postgresql process or connection. > PostgreSQL: Documentation: 18: 53.5. pg_backend_memory_contexts > > > Thank you, > Rahila Syed > > > > --0000000000002960c50640cf90a5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you so much. That helps.

I am pla= nning to use=C2=A0pg_stat_get_backend= _memory_contexts function=C2=A0something as below by=C2=A0joining th= is to the pg_stat_activity. Hope this is the right usage. Somehow i am gett= ing an error stating the function doesn't exist but it might be=C2=A0be= cause of the version. I will try with a higher version.

SELECT=C2=A0 =C2=A0pa.pid,
=C2=A0 =C2=A0 = pa.usename,
=C2=A0 =C2=A0 pa.application_name,
=C2=A0 =C2=A0 pa.state= ,
=C2=A0 =C2=A0 mc.name AS memory_context= ,
=C2=A0 =C2=A0 pg_size_pretty(mc.used_bytes) AS used_memory
FROM=C2= =A0 =C2=A0 pg_stat_activity pa
JOIN LATERAL=C2=A0 =C2=A0 pg_stat_get_bac= kend_memory_contexts(pa.pid) mc ON TRUE
WHERE=C2=A0 =C2=A0 pa.pid <&g= t; pg_backend_pid()
ORDER BY=C2=A0=C2=A0 =C2=A0 mc.used_bytes DESC;

However, is the below query, which was sha= red by Veem in above email thread is also going to give similar memory cons= umption information i.e. Avg memory consumption per query=C2=A0from pg_stat= _statements?

WITH block_size AS (
=C2=A0 SELECT = setting::int AS size FROM pg_settings WHERE name =3D 'block_size')
SELECT
=C2=A0 query,
=C2=A0 calls,
=C2=A0 pg_size_pretty(te= mp_blks_read * bs.size) AS temp_read_in_bytes,
=C2=A0 pg_size_pretty(tem= p_blks_written * bs.size) AS temp_written_in_bytes
FROM pg_stat_statemen= ts, block_size bs
WHERE temp_blks_read > 0 OR temp_blks_written > = 0
ORDER BY temp_blks_written DESC
LIMIT 10;


On Fri, Oct 10, 2025 at 4:08=E2=80=AFPM Rahila Syed= <rahilasyed90@gmail.com&g= t; wrote:
Hi,

The ot= her question I had was , are there any pg_* views using which, we are able = to see which session/connection is using the highest amount of memory? I do= n't=C2=A0see any such columns=C2=A0in pg_stats_activity

From a purely postgresql database point of view,=C2=A0 th= is feature is being developed, you can view it here :=C2=A0 PostgreSQL= : Enhancing Memory Context Statistics Reporting=C2=A0
Basically, thi= s lets you provide the pid of any PostgreSQL process to an sql function, wh= ich then returns its memory usage statistics.=C2=A0=C2=A0
Once this feat= ure is committed, for obtaining=C2=A0memory usage statistics of any postgre= sql session you would need to run=C2=A0
SELECT pg_backend_pid() which wi= ll give you the pid of the postgresql backend.
You can then pass it to = SELECT pg_get_process_memory_contexts(pid, ..),=C2=A0 which will return the= memory consumption data.=C2=A0
This is for future reference.

At = the moment, you can use the following function on the connection whose memo= ry you wish to inspect.=C2=A0=C2=A0
This works only for local connection= i.e you can't use this function to query the=C2=A0statistics of any ot= her=C2=A0
postgresql process or connection.=C2=A0
PostgreSQL: Documentation: 18: 53.5.=C2=A0pg_backend_memory_co= ntexts

Thank you,
Rahila Syed


=C2=A0
<= /div>
--0000000000002960c50640cf90a5--