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 that way 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 corner case 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
