Alerting on memory use and instance crash
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
On Wed, Oct 8, 2025 at 11:42 AM sud <suds1434@gmail.com> 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" 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?
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!
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" 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
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
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 PM Adrian Klaver <adrian.klaver@aklaver.com>
wrote:
Show quoted text
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" 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.html2)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
On Wed, Oct 8, 2025 at 2:58 PM sud <suds1434@gmail.com> wrote:
[snip]
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?
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.
On Wed, Oct 8, 2025 at 9:52 PM 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 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 levelbut
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.html2)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
--
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!
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.
On Thu, Oct 9, 2025 at 12:37 AM Ron Johnson <ronljohnsonjr@gmail.com> wrote:
Show quoted text
On Wed, Oct 8, 2025 at 2:58 PM sud <suds1434@gmail.com> wrote:
[snip]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?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.On Wed, Oct 8, 2025 at 9:52 PM 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 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 levelbut
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.html2)Is there a way to fetch the data from pg_* view to highlight the
specific connection/session/sqls which is using high memory inpostgres?
Appreciate your guidance.
Regards
Sud--
Adrian Klaver
adrian.klaver@aklaver.com--
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!
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.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.
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.
--
Adrian Klaver
adrian.klaver@aklaver.com
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;
On Thu, 9 Oct 2025 at 01:24, Adrian Klaver <adrian.klaver@aklaver.com>
wrote:
Show quoted text
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.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.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.--
Adrian Klaver
adrian.klaver@aklaver.com
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
</messages/by-id/CAH2L28v8mc9HDt8QoSJ8TRmKau_8FM_HKS41NeO9-6ZAkuZKXw@mail.gmail.com>
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
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 = '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 PM Rahila Syed <rahilasyed90@gmail.com> wrote:
Show quoted text
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_activityFrom a purely postgresql database point of view, this feature is being
developed, you can view it here : PostgreSQL: Enhancing Memory Context
Statistics Reporting
</messages/by-id/CAH2L28v8mc9HDt8QoSJ8TRmKau_8FM_HKS41NeO9-6ZAkuZKXw@mail.gmail.com>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
On Fri, Oct 10, 2025 at 8:58 PM sud <suds1434@gmail.com> wrote:>
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;
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]PostgreSQL: Enhancing Memory Context Statistics Reporting </messages/by-id/CAH2L28v8mc9HDt8QoSJ8TRmKau_8FM_HKS41NeO9-6ZAkuZKXw@mail.gmail.com>
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 </messages/by-id/CAH2L28v8mc9HDt8QoSJ8TRmKau_8FM_HKS41NeO9-6ZAkuZKXw@mail.gmail.com>
</messages/by-id/CAH2L28v8mc9HDt8QoSJ8TRmKau_8FM_HKS41NeO9-6ZAkuZKXw@mail.gmail.com>