From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: parallel restore item dependencies |
Date: | 2009-03-14 18:34:24 |
Message-ID: | 49BBF8B0.3060404@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> I wrote:
>
>> Andrew Dunstan <andrew(at)dunslane(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-03-14 19:50:51 | Re: hstore improvements? |
Previous Message | Josh Berkus | 2009-03-14 18:31:51 | Re: Has anybody think about changing BLCKSZ to an option of initdb? |