Tom Lane wrote: > Alvaro Herrera <[EMAIL PROTECTED]> writes: >> Maybe we could write a suitable test case using Martijn's concurrent >> testing framework. > > The trick is to get process A to commit between the times that process B > looks at the new and old versions of the pg_class row (and it has to > happen to do so in that order ... although that's not a bad bet given > the way btree handles equal keys). > > I think the reason we've not tracked this down before is that that's a > pretty small window. You could force the problem by stopping process B > with a debugger breakpoint and then letting A do its thing, but short of > something like that you'll never reproduce it with high probability. > > As far as Andrew's question goes: I have no doubt that this race > condition is (or now, was) real and could explain Stefan's failure. > It's not impossible that there's some other problem in there, though. > If so we will still see the problem from time to time on HEAD, and > know that we have more work to do. But I don't think that continuing > to see it on the back branches will teach us anything.
maybe the following buildfarm report means that we need a new theory :-( http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=sponge&dt=2006-08-16%2021:30:02 Stefan ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
