9.4 and reproducible "ERROR: could not read block 0 in file..."

Looked into this based on a report via IRC, and constructed the
following minimal test case. The original reporter found it in an
attempt to migrate to 9.4 from an earlier version.

(Yes, I know the function is behaving badly in that it is declared
immutable while nevertheless accessing the table. I'm sure this is
related to the problem, but (a) it presumably worked before, for
sufficient values of "worked", and (b) if it's going to be disallowed,
I think it needs to fail more cleanly than this.)

create table ftst (id integer, v text);

create function actual_v(integer) returns text
language plpgsql immutable
as $f$
declare
res text;
begin
select v into res from ftst f where f.id=$1;
return res;
end;
$f$;

insert into ftst select i, 'value '||i from generate_series(1,60) i;
create index on ftst (id);

create index on ftst (actual_v(id));

ERROR: could not read block 0 in file "base/12135/16419": read only 0 of 8192 bytes
CONTEXT: SQL statement "select v from ftst f where f.id=$1"
PL/pgSQL function actual_v(integer) line 1 at SQL statement

select * from ftst;
ERROR: could not open relation with OID 16419

(note that no file base/12135/16419 exists at this point)

This looks to me like a catalog caching issue (the "could not open"
error goes away if you reconnect the client), but I've not yet found
exactly what's going on in the code. Hypothesis: the query in the
function is trying to access the index which is being created? The
cache entry for that index isn't cleaned up when the index creation
fails?

(Possibly relevant: if you don't create the (id) index first, the
error does not occur; effect of relhasindex not being set true yet?)

--
Andrew (irc:RhodiumToad)