Re: lsyscache: free IndexAmRoutine objects returned by GetIndexAmRoutineByAmId()

Поиск
Список
Период
Сортировка
От Matthias van de Meent
Тема Re: lsyscache: free IndexAmRoutine objects returned by GetIndexAmRoutineByAmId()
Дата
Msg-id CAEze2WjBnKq6ca7HQjm8br+_8MRZZXrNWA6z8xcajTP_uNf4nA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: lsyscache: free IndexAmRoutine objects returned by GetIndexAmRoutineByAmId()  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: lsyscache: free IndexAmRoutine objects returned by GetIndexAmRoutineByAmId()
Список pgsql-hackers
On Tue, 30 Dec 2025 at 16:25, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> 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.

If it's difficult to filter out one-time leaks into the context caused
by e.g. fmgr infra, then -indeed- it's probably not worth the effort.

In which case, v3 LGTM.

Kind regards,

Matthias van de Meent
Databricks (https://www.databricks.com)



В списке pgsql-hackers по дате отправления: