Обсуждение: 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

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