Re: race condition in pg_class

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.