Hi, Please find attached the updated patches after some cleanup and test fixes.
Thank you, Rahila Syed On Tue, Feb 18, 2025 at 6:35 PM Rahila Syed <rahilasye...@gmail.com> wrote: > Hi, > >> >> Thanks for updating the patch! >> >> The below comments would be a bit too detailed at this stage, but I’d >> like to share the points I noticed. >> >> Thanks for sharing the detailed comments. I have incorporated some of them > into the new version of the patch. I will include the rest when I refine > and > comment the code further. > > Meanwhile, I have fixed the following outstanding issues: > > 1. Currently one DSA is created per backend when the first request for >> statistics is made and remains for the lifetime of the server. >> I think I should add logic to periodically destroy DSAs, when memory >> context statistics are not being *actively* queried from the backend, >> as determined by the statistics timestamp. >> > > After an offline discussion with Andres and Tomas, I have fixed this to > use > only one DSA for all the publishing backends/processes. Each backend > allocates smaller chunks of memory within the DSA while publishing > statistics. > These chunks are tracked independently by each backend, ensuring that two > publishing backends/processes do not block each other despite using the > same > DSA. This approach eliminates the overhead of creating multiple DSAs, > one for each backend. > > I am not destroying the DSA area because it stores the previously > published > statistics for each process. This allows the system to display older > statistics > when the latest data cannot be retrieved within a reasonable time. > Only the most recently updated statistics are kept, while all earlier ones > are freed using dsa_free by each backend when they are no longer needed. > . > >> 2. The two issues reported by Fujii-san here: [1]. >> i. I have proposed a fix for the first issue here [2]. >> ii. I am able to reproduce the second issue. This happens when we try >> to query statistics of a backend running infinite_recurse.sql. While I am >> working on finding a root-cause, I think it happens due to some memory >> being overwritten due to to stack-depth violation, as the issue is not >> seen >> when I reduce the max_stack_depth to 100kb. >> } >> } >> > > The second issue is also resolved by using smaller allocations within a > DSA. > Previously, it occurred because a few statically allocated strings were > placed > within a single large chunk of DSA allocation. I have changed this to use > dynamically allocated chunks with dsa_allocate0 within the same DSA. > > Please find attached updated and rebased patches. > > Thank you, > Rahila Syed >
v14-0002-Function-to-report-memory-context-statistics.patch
Description: Binary data
v14-0001-Preparatory-changes-for-reporting-memory-context-sta.patch
Description: Binary data
