Re: SQLFunctionCache and generic plans

Hi.

Tom Lane писал(а) 2025-03-30 19:10:
> I spent some time reading and reworking this code, and have
> arrived at a patch set that I'm pretty happy with. I'm not
> sure it's quite committable but it's close:
>

> 0005: This extracts the RLS test case you had and commits it
> with the old non-failing behavior, just so that we can see that
> the new code does it differently. (I didn't adopt your test
> from rules.sql, because AFAICS it works the same with or without
> this patch set. What was the point of that one again?)

The test was introduced after my error to handle case when
execution_state
is NULL in fcache->func_state list due to statement being completely
removed
by instead rule. After founding this issue, I've added a test to cover
it.
Not sure if it should be preserved.

>
> 0006: The guts of the patch. I couldn't break this down any
> further.
>
> One big difference from what you had is that there is only one path
> of control: we always use the plan cache. The hack you had to not
> use it for triggers was only needed because you didn't include the
> right cache key items to distinguish different trigger usages, but
> the code coming from plpgsql has that right.
>

Yes, now it looks much more consistent. Still going through it. Will
do some additional testing here. So far have checked all known corner
cases and found no issues.

> Also, the memory management is done a bit differently. The
> "fcontext" memory context holding the SQLFunctionCache struct is
> now discarded at the end of each execution of the SQL function,
> which considerably alleviates worries about leaking memory there.
> I invented a small "SQLFunctionLink" struct that is what fn_extra
> points at, and it survives as long as the FmgrInfo does, so that's
> what saves us from redoing hash key computations in most cases.

I've looked through it and made some tests, including ones which caused
me
to create separate context for planing. Was a bit worried that it has
gone,
but now, as fcache->fcontext is deleted in the end of function
execution,
I don't see leaks, which were the initial reason for introducing it.

--
Best regards,
Alexander Pyhalov,
Postgres Professional