Hi, How does the process know that the client backend has finished reading > stats and it can be refreshed? What happens, if the next request for > memory context stats comes before first requester has consumed the > statistics it requested? > > A process that's copying its statistics does not need to know that. Whenever it receives a signal to copy statistics, it goes ahead and copies the latest statistics to the DSA after acquiring an exclusive lwlock.
A requestor takes a lock before it starts consuming the statistics. If the next request comes while the first requestor is consuming the statistics, the publishing process will wait on lwlock to be released by the consuming process before it can write the statistics. If the next request arrives before the first requester begins consuming the statistics, the publishing process will acquire the lock and overwrite the earlier statistics with the most recent ones. As a result, both the first and second requesters will consume the updated statistics. Does the shared memory get deallocated when the backend which > allocated it exits? > > Memory in the DSA is allocated by a postgres process and deallocated by the client backend for each request. Both the publishing postgres process and the client backend detach from the DSA at the end of each request. However, the DSM segment(s) persist even after all the processes exit and are only destroyed upon a server restart. Each DSA is associated with the procNumber of a postgres process and can be re-used by any future process with the same procNumber. > > > > When statistics of a local backend is requested, this function returns > the following > > WARNING and exits, since this can be handled by an existing function > which > > doesn't require a DSA. > > > > WARNING: cannot return statistics for local backend > > HINT: Use pg_get_backend_memory_contexts instead > > How about using pg_get_backend_memory_contexts() for both - local as > well as other backend? Let PID argument default to NULL which would > indicate local backend, otherwise some other backend? > > I don't see much value in combining the two, specially since with pg_get_process_memory_contexts() we can query both the postgres backend and a background process, the name pg_get_backend_memory_context() would be inaccurate and I am not sure whether a change to rename the existing function would be welcome. Please find an updated patch which fixes an issue seen in CI runs. Thank you, Rahila Syed
v5-Function-to-report-memory-context-stats-of-a-process.patch
Description: Binary data
