On 24/7/2025 17:05, Tom Lane wrote: > Andrei Lepikhov <lepi...@gmail.com> writes: >> I see you have chosen a variant with a new enum instead of a pointer to >> a plan cache entry. I wonder if you could write the arguments >> supporting this choice? > > Pointing to a plan cache entry would often mean that the data > structure as a whole is circular (since a plan cache entry > will have a pointer to a plan). That would in particular > make it unsafe for the plan to protect its pointer by incrementing > the cache entry's refcount --- the assemblage could never go away. > So I concur with Michael that what you propose is a bad idea. I was expecting more substantial arguments. The PostgreSQL code does not restrict back-linking to the source in principle - see IndexClause::rinfo for an example. I'm not sure what the problem is with refcount - in extensions, we currently have access to the plan cache entry for prepared statements.
In this particular case, I suggested storing a pointer to the CachedPlanSource instead of the CachedPlan. For a custom plan, we won't encounter any circular references, and for a generic plan, the reference will be indirect. Of course, read and write operations should be disabled for such a pointer, and the copy operation should only duplicate the pointer itself. -- regards, Andrei Lepikhov
