Robert Haas <robertmhaas@gmail.com> writes:
> I don't believe we should be so scared of the possibility of a serious
> bug that can't be found through any of the ways we normally test that
> we aren't willing to fix problems we can readily foresee. I grant
> that there are some situations where fixing a problem might involve
> enough risk that we shouldn't attempt it, but this is (or was) pretty
> straightforward code patterned after existing logic, and I really see
> no reason to believe that anything that was wrong with it couldn't
> have been debugged easily enough.
I'm astonished that you think that. A problem here would be almost
impossible to diagnose/reproduce, I should think, given that it would
require at least two different failures (first a backend not cleaning up
after itself, and then something going wrong in autovac's drop attempt).
If you had reason to believe there was something broken there, you could
certainly hack the system enough to force it through that code sequence,
but that's basically not something that would ever happen in routine
testing. So my judgment is that the odds of bugs being introduced here
and then making it to the field outweighs the potential benefit over the
long run. We have enough hard-to-test code already, we do not need to add
more for hypothetical corner cases.
I did think of another argument on your side of this, which is that
if you imagine that there's a persistent failure to drop some temp table,
that would effectively disable autovacuum in that database. Which
would be bad. But we could address that at very minimal risk just by
moving the drop loop to after the vacuuming loop. I note that the case
I'm afraid of, a bug in the error-catching logic, could also lead to
autovacuum becoming entirely disabled if we keep the drops first.
regards, tom lane