Re: lsyscache: free IndexAmRoutine objects returned by GetIndexAmRoutineByAmId() - Mailing list pgsql-hackers

From Tom Lane
Subject Re: lsyscache: free IndexAmRoutine objects returned by GetIndexAmRoutineByAmId()
Date
Msg-id 3344999.1767108300@sss.pgh.pa.us
Whole thread Raw
In response to Re: lsyscache: free IndexAmRoutine objects returned by GetIndexAmRoutineByAmId()  (Matthias van de Meent <boekewurm+postgres@gmail.com>)
Responses Re: lsyscache: free IndexAmRoutine objects returned by GetIndexAmRoutineByAmId()
List pgsql-hackers
Matthias van de Meent <boekewurm+postgres@gmail.com> writes:
> On Tue, 30 Dec 2025 at 15:15, Álvaro Herrera <alvherre@kurilemu.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



pgsql-hackers by date:

Previous
From: Kirill Reshke
Date:
Subject: Re: REASSIGN OWNED BY alters objects in other database.
Next
From: Bryan Green
Date:
Subject: Re: Python Limited API for PL/Python on MSVC