These two recent failures look suspiciously similar:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jaguarundi&dt=2014-12-24%2021%3A03%3A05
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=kouprey&dt=2014-12-25%2018%3A43%3A17
to wit:
*** /usr/home/pgbf/buildenv/HEAD/pgsql.build/src/test/regress/expected/brin.out
Wed Dec 24 22:03:07 2014
--- /usr/home/pgbf/buildenv/HEAD/pgsql.build/src/test/regress/results/brin.out
Wed Dec 24 22:54:26 2014
***************
*** 146,151 ****
--- 146,154 ----
end loop;
end;
$x$;
+ ERROR: cache lookup failed for function 30281
+ CONTEXT: SQL statement "create temp table qry_2_ss (tid tid) ON COMMIT DROP"
+ PL/pgSQL function inline_code_block line 26 at EXECUTE statement
INSERT INTO brintest SELECT
repeat(stringu1, 42)::bytea,
substr(stringu1, 1, 1)::"char",
***
/home/markwkm/buildroot/HEAD/pgsql.24814/src/test/regress/expected/matview.out
Thu Dec 25 18:43:31 2014
---
/home/markwkm/buildroot/HEAD/pgsql.24814/src/test/regress/results/matview.out
Thu Dec 25 18:45:25 2014
***************
*** 90,97 ****
--- 90,102 ----
CREATE MATERIALIZED VIEW tvvm AS SELECT * FROM tvv;
CREATE VIEW tvvmv AS SELECT * FROM tvvm;
+ ERROR: cache lookup failed for function 30311
CREATE MATERIALIZED VIEW bb AS SELECT * FROM tvvmv;
When I saw jagarundi's failure yesterday, I figured it was something to do
with CLOBBER_CACHE_ALWAYS ... but kouprey isn't using that option AFAICS,
so that idea fails to hold water.
I don't believe that the referenced function OIDs would ever actually
exist in the database in the current regression tests; and the two failing
statements have no reason to be accessing any user-defined functions
anyway. So those OIDs are probably bogus. It seems likely that something
is clobbering storage that is later expected to hold an OID. Whatever's
going on, it's likely that this is a recently-introduced bug, because
I don't recall seeing reports like these before.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
