On Fri, Jun 11, 2021 at 12:13 AM Amit Kapila <amit.kapil...@gmail.com> wrote: > Do we invalidate relcache entry if someone changes say trigger or some > index AM function property via Alter Function (in our case from safe > to unsafe or vice-versa)? Tsunakawa-San has mentioned this as the > reason in his email [1] why we can't rely on caching this property in > relcache entry. I also don't see anything in AlterFunction which would > suggest that we invalidate the relation with which the function might > be associated via trigger.
Hmm. I am not sure index that AM functions really need to be checked, but triggers certainly do. I think if you are correct that an ALTER FUNCTION wouldn't invalidate the relcache entry, which is I guess pretty much the same problem Tom was pointing out in the thread to which you linked. But ... thinking out of the box as Tom suggests, what if we came up with some new kind of invalidation message that is only sent when a function's parallel-safety marking is changed? And every backend in the same database then needs to re-evaluate the parallel-safety of every relation for which it has cached a value. Such recomputations might be expensive, but they would probably also occur very infrequently. And you might even be able to make it a bit more fine-grained if it's worth the effort to worry about that: say that in addition to caching the parallel-safety of the relation, we also cache a list of the pg_proc OIDs upon which that determination depends. Then when we hear that the flag's been changed for OID 123456, we only need to invalidate the cached value for relations that depended on that pg_proc entry. There are ways that a relation could become parallel-unsafe without changing the parallel-safety marking of any function, but perhaps all of the other ways involve a relcache invalidation? Just brainstorming here. I might be off-track. -- Robert Haas EDB: http://www.enterprisedb.com
