| From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: cache invalidation for PL/pgsql functions |
| Date: | 2015-04-28 19:41:33 |
| Message-ID: | CAHyXU0wYKStLcAWy6CLEqwnoKZNtH3mPm-gGHdZGn41m0-tTWQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Apr 28, 2015 at 12:43 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> I hate to use the term "bug" for what somebody's probably going to
> tell me is acceptable behavior, but that seems like a bug. I guess
> the root of the problem is that PL/plgsql's cache invalidation logic
> only considers the pg_proc row's TID and xmin when deciding whether to
> recompile. For base types that's probably OK, but for composite
> types, not so much.
It was a missed case in the invalidation logic. plpgsql was
deliberately modified to invalidate plans upon schema changes -- this
is a way to outsmart that system. definitely a bug IMNSHO.
merlin
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2015-04-28 19:46:22 | Re: COPY and file_fdw with fixed column widths |
| Previous Message | Peter Geoghegan | 2015-04-28 19:40:38 | Re: INSERT ... ON CONFLICT syntax issues |