Subject: Alerting on memory use and instance crash

From: sud <[email-masked]>
Date: Wed, 8 Oct 2025 21:12:05 +0530

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" 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 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?
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

---

From: Ron Johnson <[email-masked]>
Date: Wed, 8 Oct 2025 12:21:53 -0400

> have alerts on the specific instance crash?

In Postgresql, cluster == instance.  That's a historical fluke which might
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 == 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?
>

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

---

From: Adrian Klaver <[email-masked]>
Date: Wed, 8 Oct 2025 09:22:27 -0700

On 10/8/25 08:42, sud wrote:
> 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" 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 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?

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

-- 
Adrian Klaver
[email-masked]

---

From: sud <[email-masked]>
Date: Thu, 9 Oct 2025 00:28:11 +0530

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.

---

From: Ron Johnson <[email-masked]>
Date: Wed, 8 Oct 2025 15:06:58 -0400

On Wed, Oct 8, 2025 at 2:58 PM sud <[email-masked]> wrote:
[snip]

> views in aws aurora postgres too?
>

Yup.

> Pardon if it's a silly one to ask.
>

A Google for "what's the difference between Oracle and Postgresql" _might_
help.  I've never done that, so don't know what you'll find.

As far as how Aurora works... you need to ask AWS.  It's been too heavily
modified for a list dedicated to pure/unmodified Postgresql to help.

---

From: sud <[email-masked]>
Date: Thu, 9 Oct 2025 01:20:22 +0530

Thank you.

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: Adrian Klaver <[email-masked]>
Date: Wed, 8 Oct 2025 12:54:44 -0700

On 10/8/25 11:58, sud wrote:
> 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.
> 

It would be helpful if you specified exactly what variety of Postgres 
you are using and it's version.

If you are using AWS Aurora Postgres then you will need to look at pages 
like this:

https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Managing.html

This list is for the community version of Postgres and it's been a long 
time since AWS saw fit to have someone on the list and when they where 
here they did not really provide answers.

---

From: veem v <[email-masked]>
Date: Thu, 9 Oct 2025 20:51:56 +0530

My 2cents:-
In regards to the memory consumption question of OP:- Wouldn't the column
"temp_blks_read" and "temp_blks_written" in pg_stats_statements provide
details around the memory consumption i.e. when the query exceeds the
work_mem then it tries occupying the temp blocks. Something as below.
Correct me if I'm wrong.

WITH block_size AS (
  SELECT setting::int AS size FROM pg_settings WHERE name = '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;

---

From: Rahila Syed <[email-masked]>
Date: Fri, 10 Oct 2025 16:08:43 +0530

Hi,

> 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
<https://www.postgresql.org/message-id/flat/[email-masked]>

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
<https://www.postgresql.org/docs/current/view-pg-backend-memory-contexts.html>

Thank you,
Rahila Syed

---

From: sud <[email-masked]>
Date: Fri, 10 Oct 2025 20:57:47 +0530

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 (

On Fri, Oct 10, 2025 at 4:08 PM Rahila Syed <[email-masked]> 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: Rahila Syed <[email-masked]>
Date: Tue, 4 Nov 2025 10:06:33 +0530

On Fri, Oct 10, 2025 at 8:58 PM sud <[email-masked]> wrote:>
> 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.
> ORDER BY     mc.used_bytes DESC;

The function pg_stat_get_backend_memory_contexts(pid) is not available in
the master branch yet;
this feature is still under development. That is the reason you are getting
the error stating
function doesn't exist.

When I apply the latest patch on this proposed here, [1]
that contains the said function, and run your query , I get something like
follows:

postgres=# 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_get_process_memory_contexts(pa.pid, false) mc ON TRUE
WHERE    pa.pid <> pg_backend_pid()
ORDER BY     mc.used_bytes DESC;
  pid  | usename | application_name | state |      memory_context      |
used_memory
-------+---------+------------------+-------+--------------------------+-------------
 36876 | rahila  |                  |       | TopMemoryContext         |
202 kB
 36875 |         |                  |       | TopMemoryContext         |
200 kB
 36868 |         |                  |       | TopMemoryContext         |
176 kB
 36869 |         |                  |       | TopMemoryContext         |
164 kB
 36866 |         |                  |       | TopMemoryContext         |
164 kB
 36867 |         |                  |       | TopMemoryContext         |
164 kB
 36874 |         |                  |       | TopMemoryContext         |
164 kB
 36865 |         |                  |       | TopMemoryContext         |
164 kB
 36876 | rahila  |                  |       | CacheMemoryContext       |
141 kB
 36875 |         |                  |       | CacheMemoryContext       |
141 kB
 36874 |         |                  |       | Timezones                | 99
kB
 36868 |         |                  |       | Timezones                | 99
kB
 36876 | rahila  |                  |       | Timezones                | 99
kB
 36866 |         |                  |       | Timezones                | 99
kB
 36869 |         |                  |       | Timezones                | 99
kB
 36865 |         |                  |       | Timezones                | 99
kB
 36875 |         |                  |       | Timezones                | 99
kB
 36867 |         |                  |       | Timezones                | 99
kB
 36876 | rahila  |                  |       | WAL record construction  | 42
kB
 36865 |         |                  |       | WAL record construction  | 42
kB
 36869 |         |                  |       | WAL record construction  | 42
kB
 36875 |         |                  |       | WAL record construction  | 42
kB
 36868 |         |                  |       | WAL record construction  | 42
kB
 36874 |         |                  |       | WAL record construction  | 42
kB
 36866 |         |                  |       | WAL record construction  | 42
kB
 36867 |         |                  |       | WAL record construction  | 42
kB
 36876 | rahila  |                  |       | GUC hash table           | 21
kB
 36869 |         |                  |       | GUC hash table           | 21
kB
 36868 |         |                  |       | GUC hash table           | 21
kB
 36867 |         |                  |       | GUC hash table           | 21
kB
 36875 |         |                  |       | GUC hash table           | 21
kB
 36865 |         |                  |       | GUC hash table           | 21
kB
 36866 |         |                  |       | GUC hash table           | 21
kB
 36874 |         |                  |       | GUC hash table           | 21
kB
 36875 |         |                  |       | smgr relation table      | 11
kB
 36876 | rahila  |                  |       | smgr relation table      | 11
kB
 36866 |         |                  |       | smgr relation table      | 11
kB
 36868 |         |                  |       | smgr relation table      | 11
kB
 36865 |         |                  |       | smgr relation table      | 11
kB
 36867 |         |                  |       | smgr relation table      | 11
kB
 36868 |         |                  |       | GUCMemoryContext         | 11
kB
 36876 | rahila  |                  |       | GUCMemoryContext         | 11
kB
 36866 |         |                  |       | GUCMemoryContext         | 11
kB
 36865 |         |                  |       | GUCMemoryContext         | 11
kB
 36867 |         |                  |       | GUCMemoryContext         | 11
kB
 36869 |         |                  |       | GUCMemoryContext         | 11
kB
 36874 |         |                  |       | GUCMemoryContext         | 11
kB
 36875 |         |                  |       | GUCMemoryContext         | 11
kB
 36876 | rahila  |                  |       | Relcache by OID          |
8648 bytes
 36875 |         |                  |       | Relcache by OID          |
8648 bytes
 36875 |         |                  |       | PgStat Shared Ref Hash   |
8552 bytes
 36876 | rahila  |                  |       | PgStat Shared Ref Hash   |
8552 bytes
 36874 |         |                  |       | PgStat Shared Ref Hash   |
8552 bytes
 36875 |         |                  |       | Portal hash              |
7576 bytes
 36867 |         |                  |       | LOCALLOCK hash           |
7576 bytes
 36874 |         |                  |       | LOCALLOCK hash           |
7576 bytes
 36866 |         |                  |       | LOCALLOCK hash           |
7576 bytes
 36865 |         |                  |       | LOCALLOCK hash           |
7576 bytes
 36868 |         |                  |       | LOCALLOCK hash           |
7576 bytes
 36876 | rahila  |                  |       | Portal hash              |
7576 bytes
 36875 |         |                  |       | LOCALLOCK hash           |
7576 bytes
 36876 | rahila  |                  |       | LOCALLOCK hash           |
7576 bytes
 36868 |         |                  |       | Pending Ops Table        |
7576 bytes
 36869 |         |                  |       | LOCALLOCK hash           |
7576 bytes
 36874 |         |                  |       | PrivateRefCount          |
5520 bytes
 36876 | rahila  |                  |       | PrivateRefCount          |
5520 bytes
 36866 |         |                  |       | PrivateRefCount          |
5520 bytes
 36865 |         |                  |       | PrivateRefCount          |
5520 bytes
 36869 |         |                  |       | PrivateRefCount          |
5520 bytes
 36875 |         |                  |       | PrivateRefCount          |
5520 bytes
 36867 |         |                  |       | PrivateRefCount          |
5520 bytes
 36868 |         |                  |       | PrivateRefCount          |
5520 bytes
 36876 | rahila  |                  |       | PgStat Pending           |
504 bytes
 36875 |         |                  |       | PgStat Pending           |
504 bytes
 36875 |         |                  |       | PgStat Shared Ref        |
456 bytes
 36866 |         |                  |       | MdSmgr                   |
400 bytes
 36876 | rahila  |                  |       | PgStat Shared Ref        |
384 bytes
 36874 |         |                  |       | PgStat Shared Ref        |
312 bytes
 36875 |         |                  |       | Autovacuum database list |
312 bytes
 36865 |         |                  |       | MdSmgr                   |
272 bytes
 36876 | rahila  |                  |       | MdSmgr                   |
256 bytes
 36875 |         |                  |       | MdSmgr                   |
256 bytes
 36867 |         |                  |       | MdSmgr                   |
256 bytes
 36874 |         |                  |       | MdSmgr                   |
240 bytes
 36866 |         |                  |       | ErrorContext             |
240 bytes
 36876 | rahila  |                  |       | TopPortalContext         |
240 bytes
 36865 |         |                  |       | ErrorContext             |
240 bytes
 36876 | rahila  |                  |       | TransactionAbortContext  |
240 bytes
 36876 | rahila  |                  |       | TopTransactionContext    |
240 bytes
 36867 |         |                  |       | ErrorContext             |
240 bytes
 36875 |         |                  |       | ErrorContext             |
240 bytes
 36868 |         |                  |       | Checkpointer             |
240 bytes
 36868 |         |                  |       | MdSmgr                   |
240 bytes
 36868 |         |                  |       | Pending ops context      |
240 bytes
 36868 |         |                  |       | ErrorContext             |
240 bytes
 36875 |         |                  |       | TopPortalContext         |
240 bytes
 36869 |         |                  |       | Background Writer        |
240 bytes
 36869 |         |                  |       | MdSmgr                   |
240 bytes
 36874 |         |                  |       | ErrorContext             |
240 bytes
 36875 |         |                  |       | Autovacuum Launcher      |
240 bytes
 36869 |         |                  |       | ErrorContext             |
240 bytes
 36875 |         |                  |       | TransactionAbortContext  |
240 bytes
 36875 |         |                  |       | TopTransactionContext    |
240 bytes
 36874 |         |                  |       | Wal Writer               |
240 bytes
 36876 | rahila  |                  |       | ErrorContext             |
240 bytes
(105 rows)

> 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?

This gives the memory consumed by reading in temporary files for a
particular statement or query
It does not give the complete picture of memory usage by a PostgreSQL
process. Apart
from temp_blks_read, a PostgreSQL process allocates more memory which can
be
viewed by a utility like pg_backend_memory_contexts for the backend process
attached to
the current session.

Thank you,
Rahila Syed

[1]  PostgreSQL: Enhancing Memory Context Statistics Reporting
<https://www.postgresql.org/message-id/flat/[email-masked]>