Tom Lane wrote:
I wrote:
Andrew Dunstan <[email protected]> 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
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
