| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Daniel Migowski <dmigowski(at)ikoffice(dot)de>, 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 |
| Date: | 2019-11-28 02:42:50 |
| Message-ID: | 20191128024250.GK237562@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Sep 03, 2019 at 06:30:32PM -0400, Tom Lane wrote:
> 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.
We are a couple of months after this update, and the patch has not
been updated, so I am marking it as returned with feedack.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2019-11-28 02:45:21 | Re: POC: Cleaning up orphaned files using undo logs |
| Previous Message | Michael Paquier | 2019-11-28 02:39:42 | Re: pglz performance |