public inbox for [email protected]
help / color / mirror / Atom feedFrom: torikoshia <[email protected]>
To: Rahila Syed <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Cc: Daniel Gustafsson <[email protected]>
Subject: Re: Enhancing Memory Context Statistics Reporting
Date: Tue, 07 Oct 2025 09:51:15 +0900
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAH2L28uL=Vm9E4Uf=tkg2Ki7_uDuAXORHVyCA7K_L=PAQ2p4sA@mail.gmail.com>
References: <CAExHW5skNvp265od6XPs0O-RL3cwtgHW3N87Ob0+nByZ=_HzAA@mail.gmail.com>
<[email protected]>
<CAH2L28v9EU4dxKUpvMt_CFAzG72CYusPWxADsgT=cwFJP-fP0A@mail.gmail.com>
<[email protected]>
<[email protected]>
<CAH2L28s+s4JJdPz2RkALzOvXpxXUcmm=fvg-Y6M82g9Cp=bB-w@mail.gmail.com>
<[email protected]>
<5bxhxniyvjyfldi7yjxcnxkl3i2ghci2grjyeclrbkfqnyhowk@dfkqzbvtbpml>
<[email protected]>
<tesneyk3z2dtrjgwlmkw2wbr7e3olwkowlpke6kl463hfhxedb@fyyqsnwjcp4l>
<CAH2L28tp8RMa0CrCgdCJw20vFzeGQMuHkXAoPgYC5JZuXY8_+g@mail.gmail.com>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<CAH2L28vt16C9xTuK+K7QZvtA3kCNWXOEiT=gEekUw3Xxp9LVQw@mail.gmail.com>
<[email protected]>
<[email protected]>
<CAH2L28sc-rEhyntPLoaC2XUa0ZjS5ka6KzEbuSVxQBBnUYu1KQ@mail.gmail.com>
<CAH2L28vCCgye_+kJt22RAFzZfYbO7ytSrp-hR6-SenBcm_cN+w@mail.gmail.com>
<CAH2L28t=O1k+5wdcP88rgty3OLZisTU72WGH8Dp2MxJjwn7=fw@mail.gmail.com>
<[email protected]>
<CAH2L28sF02nZj5vEL49EsTx+TfYpB3dFgShgn0=W1V-uFZjejw@mail.gmail.com>
<[email protected]>
<CAH2L28uL=Vm9E4Uf=tkg2Ki7_uDuAXORHVyCA7K_L=PAQ2p4sA@mail.gmail.com>
On 2025-08-20 06:42, Rahila Syed wrote:
> PFA the fix.
Thanks for updating the patch!
Specifying a very small timeout value (such as 0 or 0.0001) and
repeatedly executing the function seems to cause unexpected behavior. In
some cases, it even leads to a crash.
For example:
(session1)=# select pg_backend_pid();
pg_backend_pid
----------------
50917
(session2)=# select pg_get_process_memory_contexts(50917, true,
0.0001);
pg_get_process_memory_contexts
--------------------------------
(0 rows)
(session2)=# \watch 0.01
pg_get_process_memory_contexts
--------------------------------
(,,???,,0,0,0,0,0,0,0)
...
(21 rows)
(session2)=# \watch 0.01
pg_get_process_memory_contexts
--------------------------------
(0 rows)
...
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
This issue occurs on my M1 Mac, but I couldn’t reproduce it on Ubuntu,
so it might be environment-dependent.
Looking at the logs, Assert() is failing:
2025-10-07 08:48:26.766 JST [local] psql [23626] WARNING: 01000:
server process 23646 is processing previous request
2025-10-07 08:48:26.766 JST [local] psql [23626] LOCATION:
pg_get_process_memory_contexts, mcxtfuncs.c:476
TRAP: failed Assert("victim->magic == FREE_PAGE_SPAN_LEADER_MAGIC"),
File: "freepage.c", Line: 1379, PID: 23626
0 postgres 0x000000010357fdf4
ExceptionalCondition + 216
1 postgres 0x00000001035cbe18
FreePageManagerGetInternal + 684
2 postgres 0x00000001035cbb18
FreePageManagerGet + 40
3 postgres 0x00000001035c84cc
dsa_allocate_extended + 788
4 postgres 0x0000000103453af0
pg_get_process_memory_contexts + 992
5 postgres 0x0000000103007e94
ExecMakeFunctionResultSet + 616
6 postgres 0x00000001030506b8
ExecProjectSRF + 304
7 postgres 0x0000000103050434
ExecProjectSet + 268
8 postgres 0x0000000103003270
ExecProcNodeFirst + 92
9 postgres 0x0000000102ffa398
ExecProcNode + 60
10 postgres 0x0000000102ff5050 ExecutePlan
+ 244
11 postgres 0x0000000102ff4ee0
standard_ExecutorRun + 456
12 postgres 0x0000000102ff4d08 ExecutorRun
+ 84
13 postgres 0x0000000103341c84
PortalRunSelect + 296
14 postgres 0x0000000103341694 PortalRun +
656
15 postgres 0x000000010333c4bc
exec_simple_query + 1388
16 postgres 0x000000010333b5d0
PostgresMain + 3252
17 postgres 0x0000000103332750
BackendInitialize + 0
18 postgres 0x0000000103209e48
postmaster_child_launch + 456
19 postgres 0x00000001032118c8
BackendStartup + 304
20 postgres 0x000000010320f72c ServerLoop
+ 372
21 postgres 0x000000010320e1e4
PostmasterMain + 6448
22 postgres 0x0000000103094b0c main + 924
23 dyld 0x0000000199dc2b98 start +
6076
Could you please check if you can reproduce this crash on your
environment?
And a few minor comments on the patch itself:
> + <parameter>stats_timestamp</parameter>
> <type>timestamptz</type> )
As discussed earlier, I believe we decided to remove stats_timestamp,
but it seems it’s still mentioned here.
> + * Update timestamp and signal all the waiting client backends after
> copying
> + * all the statistics.
> + */
> +static void
> +end_memorycontext_reporting(MemoryStatsDSHashEntry *entry,
> MemoryContext oldcontext, HTAB *context_id_lookup)
Should “Update timestamp” in this comment also be removed for
consistency?
The column order differs slightly from pg_backend_memory_contexts.
If there’s no strong reason for the difference, perhaps aligning the
order might improve consistency:
=# select * from pg_get_process_memory_contexts(pg_backend_pid(),
true, 1) ;
name | TopMemoryContext
ident | [NULL]
type | AllocSet
path | {1}
level | 1
total_bytes | 222400
=# select * from pg_backend_memory_contexts;
name | TopMemoryContext
ident | [NULL]
type | AllocSet
level | 1
path | {1}
total_bytes | 99232
...
Regards,
--
Atsushi Torikoshi
Seconded from NTT DATA Japan Corporation to SRA OSS K.K.
view thread (52+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected]
Subject: Re: Enhancing Memory Context Statistics Reporting
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox