From: | torikoshia <torikoshia(at)oss(dot)nttdata(dot)com> |
---|---|
To: | Rahila Syed <rahilasyed90(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Daniel Gustafsson <daniel(at)yesql(dot)se> |
Subject: | Re: Enhancing Memory Context Statistics Reporting |
Date: | 2025-10-14 09:00:45 |
Message-ID: | e42debb987c81d0fb282b90b75ffdc3a@oss.nttdata.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2025-10-09 17:43, Rahila Syed wrote:
> 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.
Thanks for the update.
v35 works fine on my environment.
I ran the same test and haven’t encountered the crash anymore.
The addition of the following code appears to have resolved the issue:
+memstats_dsa_cleanup(char *key)
+{
+ MemoryStatsDSHashEntry *entry;
+
+ entry = dshash_find(MemoryStatsDsHash, key, true);
Since you seem to make a next version patch, I understand v35 is an
interim patch,
so this isn’t a major concern, but I encountered trailing whitespace
warnings when applying the patches:
$ git apply
0001-v35-0001-Add-pg_get_process_memory_context-function.patch
0001-v35-0001-Add-pg_get_process_memory_context-function.patch:705:
trailing whitespace.
0001-v35-0001-Add-pg_get_process_memory_context-function.patch:1066:
trailing whitespace.
--
Regards,
--
Atsushi Torikoshi
Seconded from NTT DATA Japan Corporation to SRA OSS K.K.
From | Date | Subject | |
---|---|---|---|
Next Message | Andrei Lepikhov | 2025-10-14 09:11:53 | Re: Comments on Custom RMGRs |
Previous Message | Daniel Gustafsson | 2025-10-14 08:44:37 | Re: Why pg_dump overwrites dump file? |