On Tue, Aug 16, 2016 at 2:21 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > There is something rotten in the state of Denmark. Here are four recent > runs that failed with unexpected "cache lookup failed for type nnnn" > errors: > > http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=grouse&dt=2016-08-16%2008%3A39%3A03 > http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=nudibranch&dt=2016-08-13%2009%3A55%3A09 > http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=sungazer&dt=2016-08-09%2001%3A46%3A17 > http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=tern&dt=2016-08-09%2000%3A44%3A18 > > The first two are on HEAD, the second two on 9.5, which seems to rule out > my first thought that this has something to do with parallel query. It's > notable though that all the failing machines are PPC or S/390 ... maybe > big-endian related? > > I grepped through the buildfarm logs and determined that there are exactly > zero similar failures going back as far as 2016-04-01. Now that we've had > four in a week, it seems certain that this indicates a bug introduced at > most a few days before Aug 9. A quick trawl through the git logs finds > no obvious candidates, though.
Well, it would have to be something that was back-patched to 9.5, right? That doesn't leave too many candidates. [rhaas pgsql]$ git log --format=oneline --before='Aug 10' --after='Aug 6' REL9_5_STABLE src/backend/ 04cee8f835bcf95ff80b734c335927aaf6551d2d Fix several one-byte buffer over-reads in to_number 4da812fa8adb22874a937f1b000253fecf526cb0 Translation updates 98b0c6280667ce1efae763340fb2c13c81e4d706 Fix two errors with nested CASE/WHEN constructs. cb5c14984ad327e52dfb470fde466a5aca7d50a1 Fix misestimation of n_distinct for a nearly-unique column with many nulls. 71dca408c0030ad76044c6b17367c9fbeac511ec Don't propagate a null subtransaction snapshot up to parent transaction. Obviously, the third and fourth of those seem like the most likely candidates, but I don't have any theory on how either of them could be causing this. It would sure be nice if those cache lookup failure messages printed the file and line number. I wonder if we could teach psql to always treat the VERBOSITY as verbose when the error code is XX000. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers