Tom Lane wrote:
> Alvaro Herrera <alvherre@commandprompt.com> 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