I wrote: > Observe these recent buildfarm failures: > http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=mule&dt=2015-03-21%2000%3A30%3A02 > http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=guaibasaurus&dt=2015-03-23%2004%3A17%3A01 > http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=mule&dt=2015-03-31%2023%3A30%3A02
> Three similar-looking failures, on two different machines, in a regression > test that has existed for less than three weeks. Something is very wrong. I've been able to reproduce this. The triggering event seems to be that the "VACUUM FULL pg_am" in vacuum.sql has to happen while another backend is starting up. With a ten-second delay inserted at the bottom of PerformAuthentication(), it's trivial to hit it manually. The reason we'd not seen this before the rolenames.sql test was added is that none of the other tests that run concurrently with vacuum.sql perform mid-test reconnections, or ever have AFAIR. So as long as they all managed to start up before vacuum.sql got to the dangerous step, no problem. I've not fully tracked it down, but I think that the blame falls on the MVCC-snapshots-for-catalog-scans patch; it appears that it's trying to read pg_am's pg_class entry with a snapshot that's too old, possibly because it assumes that sinval signaling is alive which I think ain't so. For even more fun, try "VACUUM FULL pg_class" instead: psql: PANIC: could not open critical system index 2662 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