Re: [bug?] Missed parallel safety checks, and wrong parallel safety - Mailing list pgsql-hackers

From Greg Nancarrow
Subject Re: [bug?] Missed parallel safety checks, and wrong parallel safety
Date
Msg-id CAJcOf-cyxsSKT4eTOUmOCZyNCRFJ+dkFPN2BW7pRFiHrNO1WuA@mail.gmail.com
Whole thread Raw
In response to Re: [bug?] Missed parallel safety checks, and wrong parallel safety  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [bug?] Missed parallel safety checks, and wrong parallel safety  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Wed, May 5, 2021 at 5:09 AM Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Fri, Apr 23, 2021 at 10:53 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> > Isn't parallel safety also the C code property?
>
> > Also, if the strict property of built-in functions is fixed
> > internally, why we allow users to change it and is that of any help?
>
> One real application of allowing these sorts of changes is letting
> users correct things that were done wrong originally without waiting
> for a new major release.
>

Problem is, for built-in functions, the changes are allowed, but for
some properties (like strict) the allowed changes don't actually take
effect (this is what Amit was referring to - so why allow those
changes?).
It's because some of the function properties are cached in
FmgrBuiltins[] (for a "fast-path" lookup for built-ins), according to
their state at build time (from pg_proc.dat), but ALTER FUNCTION is
just changing it in the system catalogs. Also, with sufficient
privileges, a built-in function can be redefined, yet the original
function (whose info is cached in FmgrBuiltins[]) is always invoked,
not the newly-defined version.

Regards,
Greg Nancarrow
Fujitsu Australia



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: AlterSubscription_refresh "wrconn" wrong variable?
Next
From: Craig Ringer
Date:
Subject: Re: [PATCH] Identify LWLocks in tracepoints