Re: When deleting the plpgsql function, release the CachedPlan of the function

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>
Cc: zengman <zengman(at)halodbtech(dot)com>, pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: When deleting the plpgsql function, release the CachedPlan of the function
Date: 2025-08-18 16:38:35
Message-ID: 420591.1755535115@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com> writes:
> I'm trying to figure out how this patch is supposed to handle
> concurrent sessions dropping a procedure that has cached plans.

It doesn't, which is (one reason) why it's just a crude hack.

A more appropriate solution would be to make plpgsql install
a shared-cache-invalidation callback that would watch for
invalidations on pg_proc and mark relevant function trees as
deletable. It couldn't necessarily delete them right away,
since they might be in use at the moment the inval event
arrives. (That is, an inval might just indicate an update
not a delete. But flushing the function tree would be OK
in either case.)

I wonder if we could make src/backend/utils/cache/funccache.c
handle this, so that SQL functions could also benefit without
duplicated logic.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Filip Janus 2025-08-18 16:51:57 Re: Proposal: Adding compression of temporary files
Previous Message Jacob Champion 2025-08-18 16:20:07 Re: Proposal: Extending the PostgreSQL Protocol with Command Metadata