Stefan Kaltenbrunner wrote: > Tom Lane wrote: > > Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes: > >> FWIW: lionfish had a weird make check error 3 weeks ago which I > >> (unsuccessfully) tried to reproduce multiple times after that: > > > >> http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=lionfish&dt=2006-05-12%2005:30:14 > > > > Weird. > > > > SELECT ''::text AS eleven, unique1, unique2, stringu1 > > FROM onek WHERE unique1 < 50 > > ORDER BY unique1 DESC LIMIT 20 OFFSET 39; > > ! ERROR: could not open relation with OID 27035 > > > > AFAICS, the only way to get that error in HEAD is if ScanPgRelation > > can't find a pg_class row with the mentioned OID. Presumably 27035 > > belongs to "onek" or one of its indexes. The very next command also > > refers to "onek", and doesn't fail, so what we seem to have here is > > a transient lookup failure. We've found a btree bug like that once > > before ... wonder if there's still one left? > > FYI: lionfish just managed to hit that problem again: > > http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=lionfish&dt=2006-07-29%2023:30:06
The error message this time is ! ERROR: could not open relation with OID 27006 It's worth mentioning that the portals_p2 test, which happens in the parallel group previous to where this test is run, also accesses the onek table successfully. It may be interesting to see exactly what relation is 27006. The test alter_table, which is on the same parallel group as limit (the failing test), contains these lines: ALTER INDEX onek_unique1 RENAME TO tmp_onek_unique1; ALTER INDEX tmp_onek_unique1 RENAME TO onek_unique1; Maybe this is related. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
