From: Tom Lane <tgl@sss.pgh.pa.us>
To: Noah Misch <noah@leadboat.com>
cc: Robert Haas <robertmhaas@gmail.com>, pgsql-hackers@postgresql.org,
        Smolkin Grigory <smallkeen@gmail.com>,
        Michael Paquier <michael@paquier.xyz>
Subject: Re: race condition in pg_class
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>
Comments: In-reply-to Noah Misch <noah@leadboat.com>
	message dated "Thu, 27 Jun 2024 22:13:53 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1914891.1719551842.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Fri, 28 Jun 2024 01:17:22 -0400
Message-ID: <1914892.1719551842@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1914892.1719551842%40sss.pgh.pa.us>
Precedence: bulk

Noah Misch <noah@leadboat.com> writes:
> Pushed.  Buildfarm member prion is failing the new inplace-inval.spec, a=
lmost
> surely because prion uses -DCATCACHE_FORCE_RELEASE and inplace-inval.spe=
c 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 r=
eport
>    the final answer.  Undo in the later fix patch.

> 2. v14+ has pg_backend_memory_contexts.  In the test, run some plpgsql t=
hat
>    uses heuristics on that to deduce whether caches are getting released=
.
>    Have a separate expected output for the cache-release scenario.  Perh=
aps
>    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 o=
utput
>    for the cache-release scenario.

> Preferences or other ideas?  I'm waffling between (1) and (2).  I'll giv=
e 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