ohp@pyrenet.fr writes: > Jaguar is a new animal meant to test specific defines as asked by Tom > sometime ago. > Right now, it compiles and runs with -DCLOBBER_CACHE_ALWAYS Cool, how long does it take to run the regression tests? > Let me know if you want me to add/change flags Awhile back I got burnt by a gap in that testing methodology: http://archives.postgresql.org/pgsql-committers/2006-12/msg00237.php I didn't do anything about it at the time, but now I am tempted to modify LookupOpclassInfo() so that CLOBBER_CACHE_ALWAYS disables its internal cache. Any objections? regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate

Gregory Stark <stark@enterprisedb.com> writes: > "Tom Lane" <tgl@sss.pgh.pa.us> writes: >> I didn't do anything about it at the time, but now I am tempted to >> modify LookupOpclassInfo() so that CLOBBER_CACHE_ALWAYS disables >> its internal cache. Any objections? > That sounds not equivalent to receiving a relcache flush at any particular > point in time where a relcache flush could be received. Wouldn't it make more > sense (and test more code) to go ahead and cache all the same data but flush > it whenever a relcache flush could possibly be received? CLOBBER_CACHE_ALWAYS already did that. I'm too lazy to go back and reconstruct the exact sequence of events that led to the problem last December, but the basic issue is that LookupOpclassInfo had its own caching in front of the syscache flush, and that was able to obscure a cache flush race condition that only happened when LookupOpclassInfo had to actually load data. If you really want to question this, I suggest loading up a CVS snapshot from late last December and trying to reproduce the intermittent buildfarm failures we were seeing then. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster