On Fri, Jun 28, 2024 at 01:17:22AM -0400, Tom Lane wrote:
> Noah Misch <noah@leadboat.com> writes:
> > Pushed. Buildfarm member prion is failing the new inplace-inval.spec, almost
> > surely because prion uses -DCATCACHE_FORCE_RELEASE and inplace-inval.spec is
> > testing an extant failure to inval a cache entry. Naturally, inexorable inval
> > masks the extant bug. Ideally, I'd just skip the test under any kind of cache
> > clobber option. I don't know a pleasant way to do that, so these are
> > known-feasible things I'm considering:
>
> > 1. Neutralize the test in all branches, probably by having it just not report
> > the final answer. Undo in the later fix patch.
>
> > 2. v14+ has pg_backend_memory_contexts. In the test, run some plpgsql that
> > uses heuristics on that to deduce whether caches are getting released.
> > Have a separate expected output for the cache-release scenario. Perhaps
> > also have the test treat installcheck like cache-release, since
> > installcheck could experience sinval reset with similar consequences.
> > Neutralize the test in v12 & v13.
>
> > 3. Add a test module with a C function that reports whether any kind of cache
> > clobber is active. Call it in this test. Have a separate expected output
> > for the cache-release scenario.
>
> > Preferences or other ideas? I'm waffling between (1) and (2). I'll give it
> > more thought over the next day.
>
> I'd just go for (1). We were doing fine without this test case.
> I can't see expending effort towards hiding its result rather
> than actually fixing anything.
Good point, any effort on (2) would be wasted once the fixes get certified. I
pushed (1). I'm attaching the rebased fix patches.