From: | Man Zeng <zengman(at)halodbtech(dot)com> |
---|---|
To: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Cc: | Man Zeng <zengman(at)halodbtech(dot)com> |
Subject: | Re: When deleting the plpgsql function, release the CachedPlan of the function |
Date: | 2025-08-19 08:24:01 |
Message-ID: | 175559184125.280981.15783482937984590429.pgcf@coridan.postgresql.org |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
When a function or stored procedure is created, called, and then dropped,
the resulting CachedPlan is never released and can only be freed by exiting the session.
Meanwhile, if you create another function or stored procedure with the same name and parameters, and then call it,
you'll be able to see two separate CachedPlans via pg_get_backend_memory_contexts.
You may refer to the following test steps.
Step 1 :
create or replace procedure test_pro() as $$
declare
va int default 100;
begin
for i in 1 .. 10 loop
va := va + i;
end loop;
raise notice '%', va;
va := va;
end $$ LANGUAGE plpgsql;
Step 2:
call test_pro();
Step 3:
select * from pg_get_backend_memory_contexts() where parent = 'CacheMemoryContext' and name = 'CachedPlan';
Step 4:
drop procedure test_pro;
Step 5:
select * from pg_get_backend_memory_contexts() where parent = 'CacheMemoryContext' and name = 'CachedPlan';
Step 6:
create or replace procedure test_pro() as $$
declare
va int default 100;
begin
for i in 1 .. 10 loop
va := va + i;
end loop;
raise notice '%', va;
va := va;
end $$ LANGUAGE plpgsql;
Step 7:
call test_pro();
Step 8:
select * from pg_get_backend_memory_contexts() where parent = 'CacheMemoryContext' and name = 'CachedPlan';
From | Date | Subject | |
---|---|---|---|
Next Message | Man Zeng | 2025-08-19 08:28:37 | Re: When deleting the plpgsql function, release the CachedPlan of the function |
Previous Message | Laurenz Albe | 2025-08-19 08:19:55 | Re: Retail DDL |