Thread: Why don't you to document pg_shmem_allocations view's name list?
Hello, I think it is more useful if the name list of the pg_shmem_allocations view is listed in one page. For example, * Wal Sender Ctl: walsender-related shared memory * AutoVacuum Data: autovacuum-related shared memory * PROCLOCK hash: shared memory for hash table for PROCLOCK structs Why don't you document pg_shmem_allocations view's name list? Regards, -- Masahiro Ikeda
On Tue, May 26, 2020 at 10:16:19AM +0900, Masahiro Ikeda wrote: > I think it is more useful if the name list of the > pg_shmem_allocations view is listed in one page. > > Why don't you document pg_shmem_allocations view's name list? Documenting that would create a dependency between the docs and the backend code, with very high chances of missing doc updates each time new code that does an extra shared memory allocation is added. I think that there would be a point in bringing more sanity and consistency to the names of the shared memory sections passed down to ShmemInitStruct() and SimpleLruInit() though. -- Michael
Attachment
On 2020-05-26 11:08, Michael Paquier wrote: > On Tue, May 26, 2020 at 10:16:19AM +0900, Masahiro Ikeda wrote: >> I think it is more useful if the name list of the >> pg_shmem_allocations view is listed in one page. >> >> Why don't you document pg_shmem_allocations view's name list? > > Documenting that would create a dependency between the docs and the > backend code, with very high chances of missing doc updates each time > new code that does an extra shared memory allocation is added. I > think that there would be a point in bringing more sanity and > consistency to the names of the shared memory sections passed down to > ShmemInitStruct() and SimpleLruInit() though. > -- > Michael Thanks for replaying. I understood the reason why the name list is not documented. I agree your opinion. Regards, -- Masahiro Ikeda