From: | Noah Misch <noah(at)leadboat(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Smolkin Grigory <smallkeen(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz> |
Subject: | Re: race condition in pg_class |
Date: | 2024-06-28 05:13:53 |
Message-ID: | 20240628051353.a0.nmisch@google.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2024-06-28 05:17:22 | Re: race condition in pg_class |
Previous Message | Amit Kapila | 2024-06-28 05:11:42 | Re: speed up a logical replica setup |