On Tue, 20 Sept 2022 at 17:23, Tom Lane <t...@sss.pgh.pa.us> wrote: > "Broken" is a strong claim. There's reason to think it could fail > in the back branches, but little evidence that it actually has failed > in the field.
I've posted some code to the security list that shows that I can get MemoryContextContains() to return true when it should return false. This results in the datumCopy() in eval_windowfunction() being skipped and the result of the window function being left in the incorrect memory context. I was unable to get this to produce a crash, but if there's some way to have the result point into a shared buffer page and that page is evicted and replaced with something else before the value is used then we'd have issues. > So yeah, we have work to do --- which is the exact > opposite of your apparent stand that we can walk away from the > problem. My problem is that I'm unable to think of a way to fix something I see as an existing bug. I've given it a week and nobody else has come forward with any proposals on how to fix this. I'm very open to finding some way to allow us to keep this optimisation, but so far I've been unable to. We have reverted broken optimisations before. Also, reverting c6e0fe1f2a does not seem that appealing to me as it just returns MemoryContextContains() back into a state where it can return false positives again. David
