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
