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
signature.asc
Description: PGP signature
