|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||Daniel Migowski <dmigowski(at)ikoffice(dot)de>|
|Cc:||Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Ibrar Ahmed <ibrar(dot)ahmad(at)gmail(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>|
|Subject:||Re: Patch: New GUC prepared_statement_limit to limit memory used by prepared statements|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
> 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
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
|Next Message||Alvaro Herrera||2019-09-03 22:34:34||Re: Tid scan improvements|
|Previous Message||Alvaro Herrera||2019-09-03 22:30:06||Re: Shared Memory: How to use SYSV rather than MMAP ?|