In the department of no-good-deed-goes-unpunished ...
I noticed that avocet and trilobite (two of our CLOBBER_CACHE_ALWAYS
animals) have started to fail on the deadlock-parallel isolation
test, with symptoms that look like they're timing out. Poking at
it here with a somewhat faster machine (a Mac M4), I see that under
debug_discard_caches=1 that test went from
ok 27 - deadlock-parallel 26362 ms
immediately before commit 0dca5d68d to
ok 27 - deadlock-parallel 267869 ms
immediately after. This is evidently because the test involves a lot
of evaluations of an intentionally-not-inline-able SQL function.
Previously we cached the plans for that function for the life of the
outer query, but now they're getting clobbered and rebuilt each time.
This is not wrong; the wrong behavior was hanging onto a
potentially-obsolete plan. But it's pretty unfortunate for the
runtime of this test under debug_discard_caches=1.
The simplest fix is to force that test to use debug_discard_caches=0,
but I don't love that answer. Anybody have a better idea?
It looks like the runtime of the infinite_recurse test on these
animals has taken a hit too for the same reason, and there may be
other places.
regards, tom lane
