On Mon, Jun 24, 2024 at 11:03:09AM -0400, Tom Lane wrote: > Given your point that the existing locking is just a fig leaf > anyway, maybe we could simply not have any? Then it's on the > test author to be sure that the injection point won't be > getting invoked when it's about to be removed.
That would work for me to put the responsibility to the test author, ripping out the LWLock. I was wondering when somebody would come up with a case where they'd want to point to the postmaster to do something, without really coming down to a case, so there was that from my side originally. Looking at all the points currently in the tree, nothing cares about the concurrent locking when attaching or detaching a point, so perhaps it is a good thing based on these experiences to just let this LWLock go. This should not impact the availability of the tests, either. > Or just rip > out the removal capability, and say that once installed an > injection point is there until postmaster shutdown (or till > shared memory reinitialization, anyway). But not that. Being able to remove points on the fly can be important in some cases, for example where you'd still want to issue an ERROR (partial write path is one case) in a SQL test, then remove it in a follow-up SQL query to not trigger the same ERROR. -- Michael
signature.asc
Description: PGP signature
