I wrote:
> 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
And I'd barely finished posting that before this one arrived:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=shearwater&dt=2014-12-25%2020%3A24%3A32
*** /home/buildfarm/build_root/HEAD/pgsql.32096/src/test/regress/expected/privileges.out Fri Dec 26 00:24:38 2014
--- /home/buildfarm/build_root/HEAD/pgsql.32096/src/test/regress/results/privileges.out Fri Dec 26 00:25:54 2014
***************
*** 197,202 ****
--- 197,203 ---- CREATE VIEW atestv1 AS SELECT * FROM atest1; -- ok /* The next *should* fail, but it's not implemented
thatway yet. */ CREATE VIEW atestv2 AS SELECT * FROM atest2;
+ ERROR: cache lookup failed for function 30274 CREATE VIEW atestv3 AS SELECT * FROM atest3; -- ok /* Empty view is a
cornercase that failed in 9.2. */ CREATE VIEW atestv0 AS SELECT 0 as x WHERE false; -- ok
I find it suspicious that all three examples are in the same group of
parallel tests. A possible theory is that one of these tests:
test: brin gin gist spgist privileges security_label collate matview lock replica_identity rowsecurity object_address
is doing something that has bad side-effects on concurrent sessions.
In any case, it now seems dead certain that this is a recently introduced
bug. Andres is fortunate that the first instance occurred before his
recent batch of commits, or I'd be on him to revert them. As is, though,
I'm wondering if 37de8de9e33606a043e98fee64b5595aedaa8254 could possibly
be related.
regards, tom lane