Re: pg_shmem_allocations view - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: pg_shmem_allocations view
Date
Msg-id CAB7nPqQFcNk=Ticob8qtO26++42+07NDqeDgx03dHDb3wJL2kQ@mail.gmail.com
Whole thread Raw
In response to Re: pg_shmem_allocations view  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: pg_shmem_allocations view
List pgsql-hackers
And here are some comments about patch 2:
- Patch applies with some hunks.
- Some typos are present
s#memory segments..#memory segments. (double dots)
s#NULL#<literal>NULL</> (in the docs as this refers to a value)
- Your thoughts about providing separate patches for each view? What
this patch does is straight-forward, but pg_shmem_allocations does not
actually depend on the first patch adding size and name to the dsm
fields. So IMO it makes sense to separate each feature properly.
- off should be renamed to offset for pg_get_shmem_allocations.
- Is it really worth showing unused shared memory? I'd rather rip out
the last portion of pg_get_shmem_allocations.
- For refcnt in pg_get_dynamic_shmem_allocations, could you add a
comment mentioning that refcnt = 1 means that the item is moribund and
0 is unused, and that reference count for active dsm segments only
begins from 2? I would imagine that this is enough, instead of using
some define's defining the ID from which a dsm item is considered as
active.

Regards,
-- 
Michael



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: option -T in pg_basebackup doesn't work on windows
Next
From: Peter Eisentraut
Date:
Subject: improving speed of make check-world