Re: [HACKERS] pg_shmem_allocations view - Mailing list pgsql-hackers

Hi,

On 2019-11-15 14:43:09 -0500, Robert Haas wrote:
> On Thu, May 5, 2016 at 7:01 PM Andres Freund <andres@anarazel.de> wrote:
> > Here's a rebased version.  I remember why I didn't call the column
> > "offset" (as Michael complained about upthread), it's a keyword...
> 
> This never got applied, and that annoyed me again today, so here's a
> new version that I've whacked around somewhat and propose to commit. I
> ripped out the stuff pertaining to dynamic shared memory segments,
> both because I think it might need some more thought and discussion,
> and because the part the pertains to the main shared memory segment is
> the part I keep wishing we had. We can add that other part later if
> we're all agreed on it, but let's go ahead and add this part now.

Oh, nice!  Makes sense to me to split off the dsm part.


Mildly related: I really wish we had a postmaster option that'd parse
the config file, and exit after computing the amount of shared memory
that'll be required. Would be really useful to reliably compute the
number of huge pages needed. Right now one basically needs to start pg
and parse error messages, to do so.


> + <sect1 id="view-pg-shmem-allocations">
> +  <title><structname>pg_shmem_allocations</structname></title>
> +
> +  <indexterm zone="view-pg-shmem-allocations">
> +   <primary>pg_shmem_allocations</primary>
> +  </indexterm>
> +
> +  <para>
> +   The <structname>pg_shmem_allocations</structname> view shows allocations
> +   made from the server's main shared memory segment.  This includes both
> +   memory allocated by <productname>postgres</productname> itself and memory
> +   allocated by extensions using the mechanisms detailed in
> +   <xref linkend="xfunc-shared-addin" />.
> +  </para>
> +
> +  <para>
> +   Note that this view does not include memory allocated using the dynamic
> +   shared memory infrastructure.
> +  </para>

Perhaps add the equivalent of


  <para>
   By default, the <structname>pg_config</structname> view can be read
   only by superusers.
  </para>

now that you've added the revoke (with which I agree).


> +    <tbody>
> +     <row>
> +      <entry><structfield>name</structfield></entry>
> +      <entry><type>text</type></entry>
> +      <entry>The name of the shared memory allocation. NULL for unused memory
> +      and <anonymous> for anonymous allocations.</entry>
> +     </row>

> +     <row>
> +      <entry><structfield>off</structfield></entry>
> +      <entry><type>bigint</type></entry>
> +      <entry>The offset at which the allocation starts. NULL for anonymous
> +      allocations.</entry>
> +     </row>
> +
> +     <row>
> +      <entry><structfield>size</structfield></entry>
> +      <entry><type>bigint</type></entry>
> +      <entry>Size of the allocation</entry>
> +     </row>
> +    </tbody>
> +   </tgroup>
> +  </table>

Should we note that there can be only one entry for unused and anonymous
memory? And that off will be NULL for anonymous memory?



> +    /* output all allocated entries */
> +    while ((ent = (ShmemIndexEnt *) hash_seq_search(&hstat)) != NULL)
> +    {
> +        Datum        values[PG_GET_SHMEM_SIZES_COLS];
> +        bool        nulls[PG_GET_SHMEM_SIZES_COLS];

It's very mildly odd to have three of these values/nulls arrays...

> +# shared memory usage
> +{ oid => '8613',
> +  descr => 'allocations from the main shared memory segment',
> +  proname => 'pg_get_shmem_allocations', 'prorows' => 10, 'proretset' => 't',
> +  provolatile => 's', 'prorettype' => 'record', 'proargtypes' => '',
> +  proallargtypes => '{text,int8,int8}', proargmodes => '{o,o,o}',
> +  proargnames => '{name,off,size}',
> +  prosrc => 'pg_get_shmem_allocations' },

Hm. I think the function is actually volatile, rather than stable?
Queries can trigger shmem allocations internally, right?


Greetings,

Andres Freund