Segfault in 9.0 inlining SRF

Hi folks,

I have encountered a reproducible segfault in Postgres, and confirmed
it in 9.0.1 and HEAD on three separate machines. The bug was not
present in 8.4. I've attached a copy of the SQL script I have been
using to induce the segfault.

With asserts enabled, I get a failed assertion:

TRAP: FailedAssertion("!(((list) == ((List *) ((void *)0)) ||
((((Node*)((list)))->type) == T_List)))", File: "list.c", Line: 130)

If I attach gdb to the server process, here's my backtrace as the
assert is fired:

#0 0x00007f0247f7f1b5 in raise () from /lib/libc.so.6
#1 0x00007f0247f805e0 in abort () from /lib/libc.so.6
#2 0x00000000006fbf6d in ExceptionalCondition (conditionName=<value
optimized out>,
errorType=<value optimized out>, fileName=<value optimized out>,
lineNumber=<value optimized out>) at assert.c:57
#3 0x00000000005acdbb in lappend (list=0xc49e60, datum=0xc562f0) at list.c:130
#4 0x00000000005e536f in record_plan_function_dependency
(glob=0xb6bb78, funcid=16385)
at setrefs.c:1738
#5 0x00000000005f378f in inline_set_returning_function
(root=0xb6c140, rte=0xb6bc10)
at clauses.c:4318
#6 0x00000000005eaced in inline_set_returning_functions (root=0xb6c140)
at prepjointree.c:438
#7 0x00000000005e48b8 in subquery_planner (glob=<value optimized
out>, parse=0xb6b9f0,
parent_root=0x0, hasRecursion=0 '\000', tuple_fraction=<value
optimized out>,
subroot=<value optimized out>) at planner.c:341
#8 0x00000000005e5051 in standard_planner (parse=0xb6b9f0, cursorOptions=0,
boundParams=0x0) at planner.c:200
#9 0x00000000006414b6 in pg_plan_query (querytree=0xb6b9f0, cursorOptions=0,
boundParams=0x0) at postgres.c:757
#10 0x00000000006415b4 in pg_plan_queries (querytrees=<value optimized out>,
cursorOptions=0, boundParams=0x0) at postgres.c:816
#11 0x00000000006425d0 in exec_simple_query (query_string=<value optimized out>)
at postgres.c:981
#12 0x0000000000643498 in PostgresMain (argc=<value optimized out>,
argv=<value optimized out>, username=<value optimized out>) at
postgres.c:3869
#13 0x0000000000607ba1 in BackendRun () at postmaster.c:3556
#14 BackendStartup () at postmaster.c:3241
#15 ServerLoop () at postmaster.c:1432
#16 0x000000000060a4ad in PostmasterMain (argc=3, argv=0xb645e0) at
postmaster.c:1093
#17 0x00000000005a8b70 in main (argc=3, argv=0xb645d0) at main.c:188

And then the postmaster outputs:

LOG: server process (PID 18343) was terminated by signal 6: Aborted
LOG: terminating any other active server processes
WARNING: terminating connection because of crash of another server process
DETAIL: The postmaster has commanded this server process to roll back
the current transaction and exit, because another server process
exited abnormally and possibly corrupted shared memory.
HINT: In a moment you should be able to reconnect to the database and
repeat your command.
LOG: all server processes terminated; reinitializing
LOG: database system was interrupted; last known up at 2010-10-25 07:02:45 EST
LOG: database system was not properly shut down; automatic recovery in progress
LOG: consistent recovery state reached at 0/62C768
LOG: redo starts at 0/62C768
LOG: invalid magic number 0000 in log file 0, segment 0, offset 6520832
LOG: redo done at 0/6370B8
LOG: database system is ready to accept connections

I had a go at investigating the cause of the bug, but didn't have much
success as I'm not at all familiar with the guts of the optimizer.

Cheers,
BJ