| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com> |
| Cc: | Álvaro Herrera <alvherre(at)kurilemu(dot)de>, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: lsyscache: free IndexAmRoutine objects returned by GetIndexAmRoutineByAmId() |
| Date: | 2025-12-30 15:25:00 |
| Message-ID: | 3344999.1767108300@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:
> On Tue, 30 Dec 2025 at 15:15, Álvaro Herrera <alvherre(at)kurilemu(dot)de> wrote:
>> One thing we can perhaps do is (in assert-enabled builds) to detect
>> whether memory usage for that context has increased during
>> InitIndexAmRoutine and raise a warning if so. Then extension authors
>> would realize this and have a chance to fix it promptly.
> Hmm, wouldn't we be able to detect changes in
> MemoryContextMemConsumed(ctx, counters) with one before and one after
> GetIndexAmRoutine(), such as included below?
I don't think we can do this, because there are effects that the
amhandler doesn't have control over. In particular, if we have to
load its pg_proc row into syscache during fmgr_info, I don't think
that is positively guaranteed not to leak anything. (This isn't
a factor for built-in AMs, which will take the fast path in
fmgr_info, but it will be an issue for extensions.)
I am not terribly concerned by one-time leaks of that sort, so
I don't really feel an urge to try to complain about them.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bryan Green | 2025-12-30 15:55:24 | Re: Python Limited API for PL/Python on MSVC |
| Previous Message | Kirill Reshke | 2025-12-30 15:14:41 | Re: REASSIGN OWNED BY alters objects in other database. |