Re: parallel restore item dependencies

Tom Lane wrote:
> I wrote:
>   
>> Andrew Dunstan <andrew@dunslane.net> writes:
>>     
>>> In my original patch, I looked at all the dependencies of a candidate 
>>> item ansd compared them with the dependencies of the running items to 
>>> see if there was a potential locking clash. However, Tom in his 
>>> admirable reworking of my patch, restricted the list of potential 
>>> clashing items (lockDeps) to "TABLE" items, if any. This would probably 
>>> have been ok if we hadn't just beforehand transferred all TABLE 
>>> dependencies in POST_DATA items to the corresponding TABLE DATA item. 
>>> The result is that we get empty lockDeps lists on all items - I'm 
>>> surprised we haven't had more complaints about deadlock or failing locks.
>>>       
>
>   
>> [ scratches head... ]  I coulda sworn I tested that when I was hacking
>> it.  I'm running low on steam tonight but will think more about this
>> tomorrow.
>>     
>
> I think I have reconstructed what happened: I tested this code before
> I decided that repointing the dependencies was a good idea, or else
> reordered the sequence of operations in fix_dependencies after that.
> It looks to me like the correct fix is just to look for TABLE DATA
> not TABLE while setting up lockDeps[], since all the entry types we
> care about are POST_DATA items.  Anyway, I've committed that, please
> try it.
>
>             
>   

Passes test.

Thanks.

andrew