pgsql: make_restrictinfo() failed to attach the specified

Tom Lane wrote:

Log Message:
-----------
make_restrictinfo() failed to attach the specified required_relids to
its result when the clause was an OR clause. Brain fade exposed by
example from Sebastian B?ck.

I wonder if there should be regression tests for all the bugs exposed
after 8.1 ... I mean, what stops anyone from introducing the same bugs
again?

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Alvaro Herrera <alvherre@commandprompt.com> writes:

I wonder if there should be regression tests for all the bugs exposed
after 8.1 ... I mean, what stops anyone from introducing the same bugs
again?

I've never been a fan of "regression tests" in the narrow sense of
"let's test for this specific mistake we made once". If you can devise
a test that catches a class of errors including the one you actually
made, that's a different story, because it's much more likely to catch a
real future problem.

I was thinking about adding some regression tests to exercise OR-conditions
in OUTER JOIN ON clauses, because Sebastian's examples indicate that we
haven't tested that area nearly hard enough, but I'm not in favor of
just pushing his examples into the tests as-is. (For one reason,
they'll soon stop being tests of OR-conditions at all, once I've got IN
reimplemented the way I want.)

If you want to spend some time consing up test cases, the areas I'd
suggest covering are:

1. OR clauses that actually reference both sides of the JOIN, plus
OR clauses that actually mention only the outer side or only the inner
side.

2. OR clauses consisting of AND sub-clauses where the sub-clauses are
different combinations of the above cases.

regards, tom lane

I've never been a fan of "regression tests" in the narrow sense of
"let's test for this specific mistake we made once". If you can devise
a test that catches a class of errors including the one you actually
made, that's a different story, because it's much more likely to catch a
real future problem.

Heh. See what I do is envision a future 10 years from now when the guy
who truly understands the planner and executor (Tom) has long gone and
the rest of us poor buggers keep on trying to change and fix things,
thereby recreating all these 10 year old bugs :)

Chris

Christopher Kings-Lynne wrote:

I've never been a fan of "regression tests" in the narrow sense of
"let's test for this specific mistake we made once". If you can devise
a test that catches a class of errors including the one you actually
made, that's a different story, because it's much more likely to catch a
real future problem.

Heh. See what I do is envision a future 10 years from now when the guy
who truly understands the planner and executor (Tom) has long gone and
the rest of us poor buggers keep on trying to change and fix things,
thereby recreating all these 10 year old bugs :)

That's why someone else should be studying the planner and executor code
right now ... I've long wanted to start doing it but I've been always
distracted with other minutia ...

--
Alvaro Herrera http://www.amazon.com/gp/registry/DXLWNGRJD34J
"PHP is what I call the "Dumb Monkey" language. [A]ny dumb monkey can code
something in PHP. Python takes actual thought to produce something useful."
(J. Drake)

On Wednesday 16 November 2005 21:05, Alvaro Herrera wrote:

Christopher Kings-Lynne wrote:

I've never been a fan of "regression tests" in the narrow sense of
"let's test for this specific mistake we made once". If you can devise
a test that catches a class of errors including the one you actually
made, that's a different story, because it's much more likely to catch a
real future problem.

Heh. See what I do is envision a future 10 years from now when the guy
who truly understands the planner and executor (Tom) has long gone and
the rest of us poor buggers keep on trying to change and fix things,
thereby recreating all these 10 year old bugs :)

That's why someone else should be studying the planner and executor code
right now ... I've long wanted to start doing it but I've been always
distracted with other minutia ...

If you think shared row locks and subtransactions were minutia, I think you're
the right person for the job! :-)

--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

On Wed, Nov 16, 2005 at 11:05:11PM -0300, Alvaro Herrera wrote:

Christopher Kings-Lynne wrote:

I've never been a fan of "regression tests" in the narrow sense of
"let's test for this specific mistake we made once". If you can devise
a test that catches a class of errors including the one you actually
made, that's a different story, because it's much more likely to catch a
real future problem.

Heh. See what I do is envision a future 10 years from now when the guy
who truly understands the planner and executor (Tom) has long gone and
the rest of us poor buggers keep on trying to change and fix things,
thereby recreating all these 10 year old bugs :)

That's why someone else should be studying the planner and executor code
right now ... I've long wanted to start doing it but I've been always
distracted with other minutia ...

Sure, but people make mistakes. Incredibly, I think you can even find
evidence of Tom making mistakes if you dig deep enough into commit logs
and list archives! ;)

I certainly agree that a test that will catch multiple errors is better
than one that catches few (or only one), but isn't a test for a specific
case better than none at all? Is the concern how long make check takes?
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

Jim C. Nasby wrote:

isn't a test for a specific
case better than none at all? Is the concern how long make check takes?

It shouldn't be, since we can (and do) have multiple regression test
sets. If there are tests that take too long for normal use, let's make a
"takes a long time" set and a new Makefile target for it - we'll add it
to the buildfarm suite so automated testing (which shouldn't care how
long it takes) will do the heavy work for us.

cheers

andrew