From: Tom Lane <tgl@sss.pgh.pa.us>
To: Noah Misch <noah@leadboat.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: pgsql-hackers@postgresql.org, Smolkin Grigory <smallkeen@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>
Subject: Re: race condition in pg_class
Date: Fri, 28 Jun 2024 01:17:22 -0400
Message-ID: <1914892.1719551842@sss.pgh.pa.us> (raw)
In-Reply-To: <20240628051353.a0.nmisch@google.com>
References: <20231027214946.79.nmisch@google.com>
<1617596.1698446455@sss.pgh.pa.us>
<20231027232612.99.nmisch@google.com>
<20231102030915.d3.nmisch@google.com>
<20240512232923.aa.nmisch@google.com>
<20240605181706.fe.nmisch@google.com>
<CA+TgmobfMU5pdXP36D5iAwxV5WKE_vuDLtp_1QyH+H5jMMt21g@mail.gmail.com>
<20240611024525.9f.nmisch@google.com>
<20240614003549.c2.nmisch@google.com>
<20240621212842.98.nmisch@google.com>
<20240628051353.a0.nmisch@google.com>
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.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, noah@leadboat.com, robertmhaas@gmail.com, smallkeen@gmail.com, michael@paquier.xyz
Subject: Re: race condition in pg_class
In-Reply-To: <1914892.1719551842@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox