stark wrote:
>> Alvaro Herrera <alvherre ( at ) commandprompt ( dot ) 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.
>>
>
> Actually I was already looking into a related issue and have some work here
> that may help with this.
>
> I wanted to test the online index build and to do that I figured you needed to
> have regression tests like the ones we have now except with multiple database
> sessions. So I hacked psql to issue queries asynchronously and allow multiple
> database connections. That way you can switch connections while a blocked or
> slow transaction is still running and issue queries in other transactions.
>
> I thought it was a proof-of-concept kludge but actually it's worked out quite
> well. There were a few conceptual gotchas but I think I have a reasonable
> solution for each.
>
>
[snip]
Can you please put the patch up somewhere so people can see what's involved?
thanks
cheers
andrew
