On Tue, Jun 15, 2021 at 09:43:31PM -0400, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > On 2021-06-15 19:26:25 -0400, Tom Lane wrote: > >> Going forward it wouldn't be a problem, but back-patching isolation > >> test cases might find it annoying. On the other hand, my nearby > >> patch to improve isolation test stability is already going to create > >> issues of that sort. (Unless, dare I say it, we back-patch that.) > > > It might be worth to back-patch - aren't there some back branch cases of > > test instability? And perhaps more importantly, I'm sure we'll encounter > > cases of writing new isolation tests in the course of fixing bugs that > > we'd want to backpatch that are hard to make reliable without the new > > features? > > Yeah, there absolutely is a case to back-patch things like this. Whether > it's a strong enough case, I dunno. I'm probably too close to the patch > to have an unbiased opinion about that. > > However, a quick look through the commit history finds several places > where we complained about not being able to back-patch isolation tests to > before 9.6 because we hadn't back-patched that version's isolationtester > improvements. I found 6b802cfc7, 790026972, c88411995, 8b21b416e without > looking too hard. So that history certainly suggests that not > back-patching such test infrastructure is the Wrong Thing.
I'm +1 for back-patching this class of change. I've wasted time adapting a back-patch's test case to account for non-back-patched test infrastructure changes. Every back-patch of test infrastructure has been a strict win from my perspective.
