On 7/25/16 1:50 PM, Tom Lane wrote:
There's a glibc-dependent hack in aset.c that reports any plpgsql-driven palloc or pfree against a context named "SPI Proc", as well as changes in pl_comp.c so that transient junk created during initial parsing of a plpgsql function body doesn't end up in the SPI Proc context. (I did that just to cut the amount of noise I had to chase down. I suppose in large functions it might be worth adopting such a change so that that junk can be released immediately after parsing; but I suspect for most functions it'd just be an extra context without much gain.)
Some folks do create very large plpgsql functions, so if there's a handy way to estimate the size of the function (pg_proc.prosrc's varlena size perhaps) then it might be worth doing that for quite large functions.
-- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in Treble! http://BlueTreble.com 855-TREBLE2 (855-873-2532) mobile: 512-569-9461 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
