On Fri, Nov 15, 2019 at 11:59:34AM -0800, Andres Freund wrote:
> On 2019-11-15 14:43:09 -0500, Robert Haas wrote:
>> 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.
last Friday we had a conference in Tokyo, and this has been actually
mentioned when we had an after-dinner with a couple of other hackers.
Then a couple of hours later this thread rises from the ashes.
+/* SQL SRF showing allocated shared memory */
+Datum
+pg_get_shmem_allocations(PG_FUNCTION_ARGS)
This could be more talkative.
>> +# 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?
+1.
--
Michael
