planner crash/assert hit in 8.4B1 - Mailing list pgsql-hackers

While playing with 8.4b1 against one of our production databases I 
quickly managed to run into the following assert:


Program received signal SIGSEGV, Segmentation fault.
0x082d27ef in estimate_num_groups (root=0x8566398, groupExprs=0x85b9ed8, 
input_rows=1159344) at selfuncs.c:3071
3071            Assert(rel->reloptkind == RELOPT_BASEREL);
#0  0x082d27ef in estimate_num_groups (root=0x8566398, 
groupExprs=0x85b9ed8, input_rows=1159344) at selfuncs.c:3071
#1  0x08221b1c in create_unique_path (root=0x8566398, rel=0x85b746c, 
subpath=0x85b88bc, sjinfo=0x85b15cc) at pathnode.c:960
#2  0x08205484 in make_join_rel (root=0x8566398, rel1=0x85b0490, 
rel2=<value optimized out>) at joinrels.c:696
#3  0x082056fe in join_search_one_level (root=0x8566398, level=5, 
joinrels=0x85b225c) at joinrels.c:277
#4  0x081f86c3 in standard_join_search (root=0x8566398, levels_needed=5, 
initial_rels=0x85b21f0) at allpaths.c:899
#5  0x081f9a9b in make_rel_from_joinlist (root=0x8566398, 
joinlist=<value optimized out>) at allpaths.c:836
#6  0x081f9b6b in make_one_rel (root=0x8566398, joinlist=0x85b05f4) at 
allpaths.c:97
#7  0x0820e70f in query_planner (root=0x8566398, tlist=0x85ac6f4, 
tuple_fraction=0, limit_tuples=-1, cheapest_path=0xbfaac15c,    sorted_path=0xbfaac158, num_groups=0xbfaac150) at
planmain.c:252
#8  0x0820fc62 in grouping_planner (root=0x8566398, tuple_fraction=0) at 
planner.c:1007
#9  0x082119b0 in subquery_planner (glob=0x85a2c50, parse=0x856603c, 
parent_root=0x0, hasRecursion=0 '\0', tuple_fraction=0,    subroot=0xbfaac2a8) at planner.c:482
#10 0x08211f1b in standard_planner (parse=0x856603c, cursorOptions=0, 
boundParams=0x0) at planner.c:191
#11 0x0826631f in pg_plan_query (querytree=0x856603c, cursorOptions=0, 
boundParams=0x0) at postgres.c:697
#12 0x08266423 in pg_plan_queries (querytrees=0x85a112c, 
cursorOptions=0, boundParams=0x0) at postgres.c:756
#13 0x08266cb2 in exec_simple_query (query_string=0x8565244 "SELECT * 
FROM table5 WHERE t_id IN ( SELECT pl_value::integer FROM v_view1);")    at postgres.c:920
#14 0x082684f6 in PostgresMain (argc=4, argv=0x850ffc8, 
username=0x850ff98 "postgres") at postgres.c:3606
#15 0x08232ea1 in ServerLoop () at postmaster.c:3331
#16 0x08233c0c in PostmasterMain (argc=3, argv=0x84e11c8) at 
postmaster.c:1054
#17 0x081d6c97 in main (argc=3, argv=0x84e11c8) at main.c:188

A simple testcase to reproduce might be:

CREATE TABLE table1 (p_id integer, pl_key text, pl_value text);
CREATE TABLE table2 (p_id integer);
CREATE TABLE table3 (sp_id integer, p_id integer, u_id integer);
CREATE TABLE table4 (u_id integer);
CREATE VIEW v_view1 AS    SELECT sp.sp_id, u.u_id, pl.pl_key, CASE WHEN ((pl.pl_key)::text <> 
'foobar'::text) THEN pl.pl_value WHEN (((pl.pl_key)::text = 'baz'::text) 
AND (u.u_id IN (SELECT sp.u_id FROM table3 sp, table2 p WHERE sp.p_id = 
p.p_id))) THEN pl.pl_value ELSE '0'::text END AS pl_value FROM table4 u, 
table3 sp, table2 p, table1 pl WHERE ((u.u_id = sp.u_id) AND (sp.p_id = 
p.p_id)) AND (p.p_id = pl.p_id);
CREATE TABLE table5 (t_id integer);
SELECT * FROM table5 WHERE t_id IN (SELECT pl_value::integer FROM v_view1);




Stefan