Hi, I've included some additional description inline and attached rebased patches after CFbot reported a conflict.
> *DSA APIs and CFI Handler Safety*: DSA APIs, being high-level, are unsafe > to call from the CFI handler, > which can be invoked from low-level code. This concern was particularly > raised for APIs like `dsa_allocate()` > and `dsa_create()`. > To resolve this, these APIs have been moved out of the CFI handler > function. Now, the dynamic shared memory > needed to store the statistics is allocated and deleted in the client > function. The only operation performed in the CFI > handler is `dsm_attach()`, which attaches to DSA for copying statistics. > Since dsm_attach() only maps the existing > DSM into the current process address space and does not create a new DSM, > I don't see any specific reason why > it would be unsafe to call it from the CFI handler. > > Following are the details about the use of DSM in the patch: - DSA Creation: A Dynamic Shared Area (DSA) is used to store memory context statistics. - Client Process: When fetching memory context statistics, the client allocates a 1 MB chunk in the DSA, reads the statistics from the memory chunk, copies it into a tuple store, and then frees the chunk. - Storage: Pointers to these chunks are stored in a DSHASH table indexed by the client’s proc number. Each entry in the DSHASH table also stores additional metadata related to the client’s request. - Attachment: Backends only attach to the DSM segments for the DSA and DSHASH table when necessary i.e when a process queries memory context statistics or is queried by another backend. Once attached, they remain so until the session ends, at which point they remove their DSHASH entry if any and detach from DSA and DSHASH segments. - Lifecycle: The DSA and DSHASH structures are created upon the first SQL function invocation and destroyed on server restart. > *Error Reported in Thread [2]*: This issue has been fixed by switching to > a NULL resource owner before attaching > to DSM in the CFI handler. > > This error mentioned in thread [2] is triggered during CFI() call from secure_read() when a backend is waiting for commands and it has an open transaction which is going to abort Below are some details about this fix. It is safe to temporarily set the resource owner to NULL before attaching to the DSA and DSHASH, since these segments are intended to be attached for the full session and are detached only when the session ends. We also restore the original resource owner immediately after the attach completes. Other possible fixes include: 1.Adjusting resource‑owner behavior Either allow resource‑owner enlargement during release, or delay marking it as releasing until the abort actually begins. 2. Updating DSM registry APIs (e.g., GetNamedDSA) Detect when the current resource owner is in a releasing state and temporarily set CurrentResourceOwner to NULL before calling dsa_attach. 3. Handling it in the DSA layer This was discussed in thread [2], but concerns were raised that DSA should not compensate for incorrect caller state; the caller must ensure the resource owner is valid. Kindly let me know your views. Thank you, Rahila Syed [2]. PostgreSQL: Re: Prevent an error on attaching/creating a DSM/DSA from an interrupt handler <https://www.postgresql.org/message-id/flat/8B873D49-E0E5-4F9F-B8D6-CA4836B825CD%40yesql.se#7026d2fe4ab0de6dd5decd32eb9c585a>
v46-0002-Test-module-to-test-memory-context-reporting-wit.patch
Description: Binary data
v46-0001-Add-function-to-report-memory-context-statistics.patch
Description: Binary data
