On 7/5/16 4:03 PM, Kouber Saparev wrote:
> Could such a memory consumption be related to a GET DIAGNOSTICS plpgsql
> block? The delete itself is within a stored procedure, and then I return
> the amount of the deleted rows from the function:
Looking at the code, no, GET DIAG won't change anything;
exec_stmt_execsql() is simply remembering the count returned by SPI; it
has no idea whether anything will end up using that count.
The only thing I can think of is that you have triggers that are
consuming the memory (either the trigger funcs, or because it's an
after/constraint trigger), or that there's something screwy with finding
the target rows. I can't see how the latter could be an issue if id is a
simple int though.
There are ways to get memory debug info, but I'm not sure if they'd
really be safe to use in production (in particular, they require
stopping the process by attaching gdb and calling a function. I think
you also need a special compile.)
--
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