On Sun, Jul 25, 2021 at 12:03:25PM -0400, Tom Lane wrote:
> The cause of the failure of course is that cache clobbering includes
> plan cache clobbering, so that the prepared statement's plan is
> remade each time it's used, not only twice as the test expects.
> However, remembering that cache flushes can happen for other reasons,
> it's my guess that this test case would prove unstable in the buildfarm
> even without considering the CLOBBER_CACHE_ALWAYS members. For example,
> a background autovacuum hitting the "test" table at just the right time
> would result in extra planning. We haven't seen that because the
> buildfarm's not running this test, but that's about to change.
Indeed.
> So AFAICS this test is inherently unstable and there is no code bug
> to be fixed. We could drop the "plans" column from this query, or
> print something approximate like "plans > 0 AND plans <= calls".
> Thoughts?
I think we should go with the latter. Checking for a legit value, even if it's
a bit imprecise is still better than nothing.
Would it be worth to split the query for the prepared statement row vs the rest
to keep the full "plans" coverage when possible?
