Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers