On Sun, Nov 27, 2016 at 10:30 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> I think you made this considerably more fragile with those changes.
>
> This code will only ever run at all in corner cases --- cases that
> almost by definition will go untested in the standard regression tests.
> The problems you suggest it has are corner-squared or corner-cubed cases.
> We were rather fortunate to find the bugs in the committed version before
> it got into the field, and would be even less likely to find bugs in code
> that is meant to run in corner-squared cases. So, with all due respect,
> I think your priorities here are entirely backwards.
I am of the contrary opinion - I think *your* priorities are
backwards. Describing those as corner-squared or corner-cubed cases
is misleading; it is true that they will arise for very few users, but
they may be catastrophic when they do arise. On the other hand, the
logic you've removed might have been bug-free (in which case removing
it is strictly a loss) or it might have had only bugs without any
particularly serious consequences (in which case you've traded little
problems for big ones). Even if it does have a serious bug, there's
no reason to suppose it will be impossible to find; why shouldn't the
BF or beta testing or dev testing reveal it, just as it revealed this
bug?
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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company