| From: | Kirill Reshke <reshkekirill(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Dilip Kumar <dilipbalaut(at)gmail(dot)com>, exclusion(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #19026: ResourceOwnerForget can't find owner for invalid plancache |
| Date: | 2025-08-20 17:35:48 |
| Message-ID: | CALdSSPhMfackgEn+8vc9N-9eSoSPSrQKUgJFdka2oXDd5Xzwvw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Wed, 20 Aug 2025 at 21:57, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> The reason this broke at 0313c5dc6 is that that enabled
> SQLFunctionCaches to be re-used for the life of the associated
> FmgrInfo, and when we are talking about an opclass support procedure,
> that FmgrInfo is in the relcache so it is likely to last for the
> life of the session. So the presented test case causes us to error
> out of execution of the SQL function during the first INSERT, but
> its SQLFunctionCache still exists and has fcache->cplan != NULL,
> even though error cleanup would've released the reference count
> already. When we come back to this point in the second INSERT,
> init_execution_state is fooled into trying to release the
> already-released cplan.
Thank you for this explanation. I understood how things got buggy and
how they should be fixed.
The v3 LGTM.
--
Best regards,
Kirill Reshke
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2025-08-21 01:48:31 | Re: Postgres: Queries are too slow after upgrading to PG17 from PG15 |
| Previous Message | Tom Lane | 2025-08-20 16:57:21 | Re: BUG #19026: ResourceOwnerForget can't find owner for invalid plancache |