Re: Patch: New GUC prepared_statement_limit to limit memory used by prepared statements

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Patch: New GUC prepared_statement_limit to limit memory used by prepared statements
Дата
Msg-id 9900.1567549832@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Patch: New GUC prepared_statement_limit to limit memory used by prepared statements  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Patch: New GUC prepared_statement_limit to limit memory used byprepared statements  (Michael Paquier <michael@paquier.xyz>)
Список pgsql-hackers
I wrote:
> As far as the crash issue is concerned, I notice that right now the
> cfbot is showing green for this patch, but that seems to just be because
> the behavior is unstable.  I see crashes in "make installcheck-parallel"
> about 50% of the time with this patch applied.  Since, in fact,
> the patch is not supposed to be doing anything at all with
> prepared_statement_limit set to zero, that suggests sloppiness in the
> refactoring that was done to separate out the resource-freeing code.

Oh ... actually, I bet the problem is that the patch thinks it's okay
to immediately free space in PlanCacheRelCallback and friends, rather
than just marking invalid entries as invalid.  Nope, you cannot do that.
You can't tell whether that data is being examined in an outer call
level.

In principle I think you could decrement-the-refcount-and-possibly-free
right away on the gplan, since any outside uses of that ought to have
their own refcounts.  But the query_context data isn't refcounted.
Also, some of the failures I saw looked like premature deletion of a
plan, not query_context data, so the patch seems to be too aggressive
on that side too.

            regards, tom lane



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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: Shared Memory: How to use SYSV rather than MMAP ?
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Tid scan improvements