Andrey Zhidenkov <andrey.zhiden...@gmail.com> writes: > I see memory consumption in htop and pg_activity tools.
"top" can be pretty misleading if you don't know how to interpret its output, specifically that you have to discount whatever it shows as SHR space. That just represents the amount of the shared memory block that this process has touched so far in its lifetime; even if it appears to be growing, it's not a leak. That growth will stop eventually, once the process has touched every available shared buffer. RES minus SHR is a fairer estimate of the process's own memory consumption. I tried to reduce your example to a self-contained test case, thus: create extension if not exists plpythonu; create table test (test text); create or replace function test() returns bigint as $$ plpy.execute("insert into test(test) values ('test')") return 1 $$ language plpythonu; do $$ begin for i in 1..10000000 loop perform test(); end loop; end; $$; I do not see any significant leakage with this example. There is some memory growth, approximately 4 bytes per plpy.execute(), due to having to keep track of a subtransaction XID for each uncommitted subtransaction. That's not plpython's fault --- it would happen with any PL that executes each SQL command as a separate subtransaction, which is probably all of them other than plpgsql. And it really ought to be negligible anyway in any sane usage. It's possible that you're seeing some other, larger memory consumption; for instance, if there were triggers or foreign keys on the "test" table then perhaps there would be an opportunity for leakage in those. But without a self-contained test case or any indication of the rate of leakage you're seeing, it's hard to guess about the problem. regards, tom lane -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers