An off-list discussion with Leo Carson of SDSC led to the following
test case, which reproducibly crashes 8.4:
-- do this in the regression database, or use some other base table
create or replace view vv as
select a.unique1, b.unique2, c.tenthous, 'label'::text as lab
from tenk1 a
left join tenk1 b on a.unique1 = b.unique2
left join tenk1 c on a.unique1 = c.tenthous;
explain select * from vv where lab = 'fool';
set geqo_threshold = 2;
explain select * from vv where lab = 'fool';
The reason is that joinrels.c determines that the topmost outer join
must yield an empty result (because the constant-false condition
resulting from lab = 'fool' is attached to that join) and it then
decides that the join's RHS doesn't need to be evaluated either.
So it applies mark_dummy_rel() to that base rel. In a GEQO environment
that leads to dangling pointers, because the dummy path added to the
base rel gets recycled at the end of geqo_eval(), but the base
RelOptInfo is still alive and will be examined again later.
9.0 and HEAD don't crash on this particular test case, but they're still
putting short-lived path pointers into longer-lived data structures,
so I'm convinced that they need the fix too.
This is not that hard to fix, but it reminds me that GEQO is just really
hard to test decently. It doesn't help that the standard regression
tests fail to exercise it at all. (You can try running the regression
tests with geqo_threshold=2, but you'll get some
possibly-platform-dependent failures due to row ordering differences
from different plans getting chosen. This makes it hard to mechanize
testing.) I wonder if anyone's got any good ideas about that?
regards, tom lane