Re: Enhancing Memory Context Statistics Reporting

Hi Torikoshia,

Thank you for testing and reviewing the patch.

>
> 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?
>
>
I haven't been able to reproduce this issue on Ubuntu. A colleague also
tested it on their Mac
and didn't encounter the problem. I do have a fix in this area that I
believe should address an edge
case where data might be written to freed DSA memory.

Kindly test using the v35 patch and let me know if you still see the issue.

>
> As discussed earlier, I believe we decided to remove stats_timestamp,
> but it seems it’s still mentioned here.
>
>
>
Fixed.

> > + * 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?
>
>
Fixed.

>
> 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:
>
>
Makes sense. I will fix this in the next iteration of the patch.

I am also attaching a test which implements crash testing using injection
points.
I plan to improve the tests further to increase the test coverage of the
feature.

Thank you,
Rahila Syed