Hi, On 2019-04-30 15:11:43 -0400, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > On 2019-04-30 14:41:00 -0400, Tom Lane wrote: > > > On 2019-04-30 12:03:08 -0700, Andres Freund wrote: > > > > This is a pretty finnicky area of the code, with obviously not enough > > > > test coverage. I'm inclined to remove them from the back branches, and > > > > try to get them working in master? > > > > > > I think trying to get this "working" is a v13 task now. We've obviously > > > never tried to stress the case before, so you're neither fixing a > > > regression nor fixing a new-in-v12 issue. > > > Well, the test *do* test that a previously existing all-branches bug > > doesn't exist, no (albeit one just triggering an assert)? I'm not > > talking about making this concurrency safe, just about whether it's > > possible to somehow keep the tests. > > Well, I told you what I thought was a safe way to run the tests.
Shrug. I was responding to you talking about "neither fixing a regression nor fixing a new-in-v12 issue", when I explicitly was talking about tests for the bug this thread is about. Not sure why "Well, I told you what I thought was a safe way to run the tests." is a helpful answer in turn. I'm not wild to go for a separate TAP test. A separate initdb cycle for a a tests that takes about 30ms seems a bit over the top. So I'm inclined to either try running it in a serial step on the buildfarm (survived a few dozen cycles with -DRELCACHE_FORCE_RELEASE -DCATCACHE_FORCE_RELEASE, and a few with -DCLOBBER_CACHE_ALWAYS), or just remove them alltogether. Or remove it alltogether until we fix this. Since you indicated a preference agains the former, I'll remove it in a bit until I hear otherwise. I'll add it to my todo list to try to fix the concurrency issues for 13. Greetings, Andres Freund