Re: injection_points: canceled or terminated waiters leak their wait slots

> In this context, the revert of the revert can be translated as `git
> revert 29992a6a509b`, right? If we do that, being able to get rid of
> the alternate outputs would be super nice, and we would not even need
> to have alternate outputs like that:

Yes. If we revert 29992a6a509b, I can't reproduce any of the issues
anymore. We can still make a test modification if we want to
explicitly test for this scenario, to make sure it doesn't reappear,
but we won't need the alternative outputs or the isolationtester
modifications.

> + DO $$
> + BEGIN
> + WHILE EXISTS (SELECT FROM pg_stat_activity
> + WHERE application_name = 'isolation/wait_cleanup/s1')
> + LOOP
> + PERFORM pg_sleep(0.01);
> + PERFORM pg_stat_clear_snapshot();
> + END LOOP;
> + END$$;
>
> Even that feels like the wrong thing to do, spreading a tweak that
> ought to be simpler for folks implement tests.

We don't have to spread this around, I added this to one scenario to
explicitly test the missing last message issue. This, or the simpler
single pg_sleep call makes it deterministic. This is the part either
in this form or just as the one line pg_sleep addition that might be
worth keeping even in the 29992a6a509b direction, so we notice if the
issue comes back / still happens sometimes.

> What do you think?

I agree with the let's try the revert on master approach. That won't
help with random failures on the stable branches, but at least we are
aware why it is happening now, and later we can either apply the
revert on them, or disable these tests on them, or apply v3.

> The perfect scenario for me would be to prove that undoing
> 29992a6a509b is now really-absolutely-stable safe, as it's still a
> server bug to me to not send back this information back to the client
> on WIN32.

The question is, what would be good enough proof? I can reproduce the
walreceiver issue with around 1% failure rate on my laptop, and it
didn't reproduce even once with only reverting 29992a6a509b in more
than 5000 runs.
I'll try to do the same thing on back branches, and I'll also set it
up on github actions to test it there.