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
