On Fri, Jun 21, 2024 at 02:28:42PM -0700, Noah Misch wrote: > On Thu, Jun 13, 2024 at 05:35:49PM -0700, Noah Misch wrote: > > I think the attached covers all comments to date. I gave everything v3, but > > most patches have just a no-conflict rebase vs. v2. The exceptions are > > inplace031-inj-wait-event (implements the holding from that branch of the > > thread) and inplace050-tests-inj (updated to cooperate with inplace031). > > Much > > of inplace031-inj-wait-event is essentially s/Extension/Custom/ for the > > infrastructure common to the two custom wait event types. > > Starting 2024-06-27, I'd like to push > inplace080-catcache-detoast-inplace-stale and earlier patches, self-certifying > them if needed. Then I'll submit the last three to the commitfest. Does > anyone want me to delay that step?
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. Thanks, nm
