Re: race condition in pg_class

Noah Misch <noah(at)leadboat(dot)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.

regards, tom lane